aboutsummaryrefslogtreecommitdiffstats
path: root/sys/linux/bpf.txt
Commit message (Collapse)AuthorAgeFilesLines
* sys/linux: describe new BTF typesPaul Chaignon2024-10-101-0/+50
| | | | | | | | | | | | | Describe four new BTF types introduced in commits [1, 2, 3, 4] upstream. Note BTF_KIND_TAG was later renamed to BTF_KIND_DECL_TAG. These four types are also described in the documentation at [5]. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b1828f0b04828 2 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b5ea834dde6b6 3 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8c42d2fa4eeab 4 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6089fb325cf73 5 - https://docs.kernel.org/bpf/btf.html#btf-kind-float Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: fix linkage field of BTF_KIND_VAR typePaul Chaignon2024-10-101-1/+2
| | | | | | | | | | The linkage field of BTF type BTF_KIND_VAR isn't actually a boolean, but a flag. Given it can now take three different values [1], it doesn't match the boolean type and needs to be fixed. This commit defines it as a proper flags type. 1 - https://docs.kernel.org/bpf/btf.html#btf-kind-var Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: improve BPF program attach typesPaul Chaignon2024-09-111-3/+3
| | | | | | | | Which attach types are available to a BPF program depends on its type. We can encode this using conditional fields to reduce the time syzkaller loses on unsupported combinations of (program type; attach type). Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: improve precision of BPF attach targetsPaul Chaignon2024-09-111-5/+27
| | | | | | | | | | | | | | | How the attach target field is interpreted depends on the program type [1], which itself depends on the attach type [2] (defined in attach_type_to_prog_type upstream). This commit encodes the same in syzkaller to make the attach target field more precise. Because attach_type_to_prog_type is a simple n to 1 mapping, we can encode it as defines. We can then use those defines in conditional fields for the different types of attach targets. 1 - https://elixir.bootlin.com/linux/v6.10.9/source/kernel/bpf/syscall.c#L4098 2 - https://elixir.bootlin.com/linux/v6.10.9/source/kernel/bpf/syscall.c#L3913 Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: replace id_or_fd with more precise versionPaul Chaignon2024-09-111-29/+36
| | | | | | | | | | | | | The id_or_fd union was introduced before we had conditional fields to represent IDs or fds for BPF programs or links. The union was overapproximating those specific types. With conditional fields, we can now use information from other fields to determine precisely which type from the union is expected. For example, with BPF_PROG_ATTACH, if BPF_F_ID is the only flag, then the relative_fd field should be interpreted as a program ID. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: cover BPF tokensPaul Chaignon2024-09-091-1/+14
| | | | | | | | | | | | | | | | | | | The new BPF_TOKEN_CREATE bpf(2) command was introduced in commit [1] upstream. This command takes a BPF filesystem fd and returns a BPF token [2]. This token can then be passed to commands BPF_PROG_LOAD, BPF_MAP_CREATE, and BPF_BTF_LOAD and the kernel will use it to check if the operation is allowed. What operations a token allows is defined by the mount options of the BPF filesystem. No flags are currently supported for the BPF_TOKEN_CREATE command. The fd should point to the BPF filesystem, but we don't have a specific resource for this yet so just point to a generic fd. This command also doesn't add support for the new mount options. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=35f96de04127 2 - https://lwn.net/Articles/947173/ Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: cover value_type_btf_obj_fd field for BPF_MAP_CREATEPaul Chaignon2024-09-091-2/+5
| | | | | | | | | This new field for the bpf(2) command BPF_MAP_CREATE was introduced in [1] upstream. It is conditioned on both the map type and its flags (BPF_F_VTYPE_BTF_OBJ_FD). 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fcc2c1fb0651 Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: update BPF constantsPaul Chaignon2024-09-091-4/+4
| | | | Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: run make extractAleksandr Nogikh2024-01-301-2/+6
| | | | | Split out deprecated descriptions from socket_netlink_route_sched.txt. Adjust outdated descriptions.
* sys/linux/bpf: use nested definitions for attach flags and typesPaul Chaignon2023-12-051-2/+2
| | | | Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: move description of BPF programs to own filePaul Chaignon2023-11-281-507/+0
| | | | | | | | | | | | | | The bpf.txt file is becoming huge as it contains the descriptions for all the bpf(2) commands. The most complex command to describe is currently BPF_PROG_LOAD has it contains the whole BPF program description. Those descriptions are also likely to grow significantly as we add more BPF helper descriptions. This commit therefore moves the descriptions pertaining to BPF programs (attributes for BPF_PROG_LOAD, eBPF instructions, and BPF helpers) to their own file, bpf_prog.txt. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: simplify BPF descriptions with new unified const/flagsPaul Chaignon2023-11-281-16/+16
| | | | Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: support more complex bpf_snprintf modifiersPaul Chaignon2023-11-271-1/+1
| | | | | | | | This commit adds more complex format modifiers for the bpf_snprintf BPF helper. Those correspond to a bunch of cases that are uncovered in syzbot's coverage of bpf_bprintf_prepare. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: add all format specifiers for bpf_trace_printkPaul Chaignon2023-11-271-4/+16
| | | | | | | | The bpf_trace_printk helper supports a limited set of format specifiers [1]. This commit ensures they are all covered in the union. 1 - https://man7.org/linux/man-pages/man7/bpf-helpers.7.html Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: fix comments for bpf_trace_printk helperPaul Chaignon2023-11-271-2/+2
| | | | | | | The comments for the two strings in bpf_insn_mov_printk_str_hex are inverted. "%p" is 0x257000 in hexa. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: add BPF_RB_* flags for ringbuf helpersPaul Chaignon2023-11-091-4/+6
| | | | | | | | | | | | | BPF helpers bpf_ringbuf_{discard,submit,output} take a set of flags. This commit describes those flags. The default is a zero value, but the kernel doesn't have a macro for that. Thus, "0" is simply added to the flag definition. Note bpf_ringbuf_reserve also has a flags argument, but it is currently unused on the kernel side. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: describe BPF helper bpf_ringbuf_outputPaul Chaignon2023-11-091-0/+20
| | | | | | | | | | | | | This helper has the prototype: bpf_ringbuf_output(void *ringbuf, void *data, u64 size, u64 flags) We need to prepare the second argument (R2) on the stack. We use an 8 bytes data value initialized to some random value on the stack and pointed to by R2. The third argument therefore needs to be 8 (for 8 bytes). Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: describe BPF helper call to bpf_ringbuf_queryPaul Chaignon2023-11-091-0/+10
| | | | | | | | This BPF helper has the prototype: bpf_ringbuf_query(void *ringbuf, u64 flags) Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: describe call to BPF helper bpf_ringbuf_discardPaul Chaignon2023-11-091-4/+6
| | | | | | | | Including this helper call in our descriptions is trivial since it takes the same arguments and returns the same (void) as the already described bpf_ringbuf_submit helper call. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: add null check BPF instructionsPaul Chaignon2023-11-091-5/+27
| | | | | | | | | | | | | | | | | | This commit adds a new struct with two BPF instructions to perform a null check on a given pointer. It is then used to update our small ringbuf program to null check the ringbuf reserved data pointer as follows. u64 *e; e = bpf_ringbuf_reserve(&rb, sizeof(*e), 0); if (!e) return 0; [...] bpf_ringbuf_submit(e, 0); return 0; With this null check, our test case corresponding to this program now passes the verifier and is successfully loaded. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: describe call to BPF helper bpf_ringbuf_submitPaul Chaignon2023-11-091-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This helper has the verifier prototype: .ret_type = RET_VOID, .arg1_type = ARG_PTR_TO_RINGBUF_MEM | OBJ_RELEASE, .arg2_type = ARG_ANYTHING, We therefore need to pass the pointer retrieved with bpf_ringbuf_reserve via R2. We saved that pointer to R9 so we can retrieve it from there. Since bpf_ringbuf_submit doesn't return anything, we need to write something in R0 before we exit the program. Our BPF program now looks like: u64 *e; e = bpf_ringbuf_reserve(&rb, sizeof(*e), 0); [...] bpf_ringbuf_submit(e, 0); return 0; It will still fail, but with EACCES instead of EINVAL, due to the following verifier error: 0: R1=ctx(off=0,imm=0) R10=fp0 0: (18) r0 = 0x0 ; R0_w=0 2: (18) r1 = 0xffff984f66f93600 ; R1_w=map_ptr(off=0,ks=0,vs=0,imm=0) 4: (b7) r2 = 20 ; R2_w=20 5: (b7) r3 = 0 ; R3_w=0 6: (85) call bpf_ringbuf_reserve#131 ; R0_w=ringbuf_mem_or_null(id=2,ref_obj_id=2,off=0,imm=0) refs=2 7: (bf) r9 = r0 ; R0_w=ringbuf_mem_or_null(id=2,ref_obj_id=2,off=0,imm=0) R9_w=ringbuf_mem_or_null(id=2,ref_obj_id=2,off=0,imm=0) refs=2 8: (bf) r1 = r9 ; R1_w=ringbuf_mem_or_null(id=2,ref_obj_id=2,off=0,imm=0) R9_w=ringbuf_mem_or_null(id=2,ref_obj_id=2,off=0,imm=0) refs=2 9: (b7) r2 = 0 ; R2_w=0 refs=2 10: (85) call bpf_ringbuf_submit#132 R1 type=ringbuf_mem_or_null expected=ringbuf_mem In short, we didn't check that the pointer returned by bpf_ringbug_reserve isn't null. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: describe call to BPF helper bpf_ringbuf_reservePaul Chaignon2023-11-091-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Describe a full call to bpf_ringbuf_reserve, using the map type created in the previous commit. The test corresponds to this simple line: u64 *e; e = bpf_ringbuf_reserve(&rb, sizeof(*e), 0); [...] return e; The pointer returned by bpf_ringbuf_reserve is kept in R9. The goal is to keep it around so we can use it in other instructions later; several other helpers take a pointer to ringbuf data as argument. There's of course a risk that some instruction in between will clobber R9, but I don't know another way. R9 is at least safe for calls (only R1--R5 get clobbered). We expect the program loading to fail with EINVAL because we never release the reference to the ringbuf data. The verifier will therefore reject the program with: 0: R1=ctx(off=0,imm=0) R10=fp0 0: (18) r0 = 0x0 ; R0_w=0 2: (18) r1 = 0xffff984e4b55da00 ; R1_w=map_ptr(off=0,ks=0,vs=0,imm=0) 4: (b7) r2 = 20 ; R2_w=20 5: (b7) r3 = 0 ; R3_w=0 6: (85) call bpf_ringbuf_reserve#131 ; R0_w=ringbuf_mem_or_null(id=2,ref_obj_id=2,off=0,imm=0) refs=2 7: (bf) r9 = r0 ; R0_w=ringbuf_mem_or_null(id=2,ref_obj_id=2,off=0,imm=0) R9_w=ringbuf_mem_or_null(id=2,ref_obj_id=2,off=0,imm=0) refs=2 8: (95) exit Unreleased reference id=2 alloc_insn=6 Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: describe ringbuf map creationPaul Chaignon2023-11-091-0/+3
| | | | | | | | | | | The corresponding test does the same as this map declaration: struct { __uint(type, BPF_MAP_TYPE_RINGBUF); __uint(max_entries, 256 * 1024); } rb SEC(".maps"); Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: describe call to bpf_tail_call helperPaul Chaignon2023-11-061-3/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bpf_tail_call helper has the following prototype. bpf_tail_call(void *ctx, struct bpf_map *prog_array_map, u32 index) R2 should therefore hold a pointer to a tail call map (aka, prog array map). That tail call map should be updated such that index points to another BPF program. In our case, index is hardcoded to 0. Finally, R1 should hold a pointer to the context. That is always true at the start of BPF programs so we don't change R1. If syzkaller generates other BPF instructions between the start of the program and the bpf_tail_call helper call, they might clobber the R1 register. That seems unlikely to happen in practice and it's also hard to prevent it anyway. To load the map fd into R2, we need to templatize bpf_insn_map_fd such that we can use it with a specific register and map fd. There's one special case here: we need to explicitly set R0 to 0 after the helper call because this helper has the following verifier prototype: .ret_type = RET_VOID, .arg1_type = ARG_PTR_TO_CTX, .arg2_type = ARG_CONST_MAP_PTR, .arg3_type = ARG_ANYTHING, Given the return verifier type is RET_VOID, if R0 isn't set explicitly, the verifier will complain with "R0 !read_ok" when we exit. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: describe BPF tail call mapPaul Chaignon2023-11-061-0/+17
| | | | | | | | | | | | | | | | This commit updates the BPF description to be able to prepare a tail call map referencing one BPF program. Tail call maps are called to jump from one program (caller) to another (called, referenced in the map). To that end, we must first create a map of the specific type and then update it with a BPF program fd. We follow the same approach as 93789af44b9a ("sys/linux: describe map holding constant string") to specialize the resource outputed by the map update and therefore ensure we can refer specifically to an updated tail call map. This new map will be used in a subsequent commit to perform a tail call. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: cover new BPF link_create fieldsPaul Chaignon2023-11-061-0/+6
| | | | | | | These new fields were introduced upstream in commit [1]. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=35dfaad7188cd Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: update BPF constantsPaul Chaignon2023-11-061-3/+3
| | | | | | | | These new constants were introduced in commits [1, 2] upstream. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=859051dd165ec 2 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=35dfaad7188cd Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: support new BPF opcode BPF_MEMSXPaul Chaignon2023-10-231-1/+2
| | | | | | | | | | | | | | | Commit [1] upstream added support for new sign-extended load instructions. Those instructions rely on a new mode, BPF_MEMSX, for the opcode. This commit adds that mode to the BPF description. Note that several other instructions were defined at the same type, but our BPF instruction descriptions are currently generic enough that no other changes are needed. In the future, we may want to make those descriptions more specific to avoid wasting fuzzing time on unsupported instruction formats. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1f9a1ea821ff Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: describe full call to bpf_snprintf helperPaul Chaignon2023-10-161-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit describes the full snippet of BPF bytecode required to successfully call the bpf_snprintf helper. That helper has the following prototype: long bpf_snprintf(char *str, u32 str_size, const char *fmt, u64 *data, u32 data_len) with the following verifier types: .arg1_type = ARG_PTR_TO_MEM_OR_NULL, .arg2_type = ARG_CONST_SIZE_OR_ZERO, .arg3_type = ARG_PTR_TO_CONST_STR, .arg4_type = ARG_PTR_TO_MEM | PTR_MAYBE_NULL | MEM_RDONLY, .arg5_type = ARG_CONST_SIZE_OR_ZERO, The first and fourth arguments can point to nulled buffers on the stack. The second and fifth arguments contain the sizes of those buffers. Finally, the third argument must point to a map holding a constant string; we can use the type introduced in the previous commit for that. The corresponding eBPF bytecode is kept in comment as that is much easier to parse for anyone familiar with the bytecode. In addition to the test case introduced in the next commit, this description was tested by running syzkaller with a focus on the necessary bpf syscalls. Specifically, syscalls bpf$MAP_CREATE_CONST_STR, bpf$MAP_UPDATE_CONST_STR, bpf$BPF_MAP_CONST_STR_FREEZE, bpf$PROG_LOAD, and bpf$BPF_PROG_TEST_RUN were executed on 16 VMs (with two logical cores each). Syzkaller was then able to reach the formatter parsing logic of function bpf_bprintf_prepare [1], which bpf_snprintf calls. 1 - https://github.com/torvalds/linux/blob/v6.5/kernel/bpf/helpers.c#L875 Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: describe map holding constant stringPaul Chaignon2023-10-161-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This goal of this commit is to prepare a map whose value will be of type ARG_PTR_TO_CONST_STR when seen by the BPF verifier [1]. To that end, the map must be read-only, of a type that allows direct map value access (only array maps), and frozen. In addition, it must contains a zero-terminated string as its value. This commit therefore defines a new bpf$MAP_CREATE_CONST_STR syscall description to create a read-only array map of fixed size. A new bpf$MAP_UPDATE_CONST_STR syscall description then updates the map with a zero-terminated string. Finally, bpf$BPF_MAP_CONST_STR_FREEZE freezes the map to prevent any other updates from the syscall side (BPF side updates are already prevented since the map is read-only). As a result, we want to end up with an fd to a map that has been created, updated, and frozen. To guarantee that all operations have been carried out (in the correct order) on the map, we change the map fd after each operation with the following example syntax: map_bpf_const_str { in fd_bpf_const_str_map out fd_bpf_const_str (out_overlay) } The 'in' fd is passed on entry to bpf$MAP_UPDATE_CONST_STR and the 'out' fd is returned. In practice, the fd value will not be changed, but this description allows us to reference the fd_bpf_const_str type in subsequent operations, thus ensuring we're using an fd to an updated map. 1 - https://github.com/torvalds/linux/blob/8a749fd1a8720d4619c91c8b6e7528c0a355c0aa/kernel/bpf/verifier.c#L8334 Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: describe full call to bpf_trace_printk helperPaul Chaignon2023-10-161-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit describes the full snippet of BPF bytecode necessary to successfully call the bpf_trace_printk helper. That helper has the following prototype: long bpf_trace_printk(const char *fmt, u32 fmt_size, ...) We thus need to initialize the fmt string on the stack, then prepare the arguments (pointer to the stack & size), before actually calling the helper. To that end, we rely on previously defined templates to express the specific instructions we need (e.g., init register with imm, perform ALU operation on register with imm). The corresponding eBPF bytecode is kept in comment as that is much easier to parse for anyone familiar with the bytecode. In addition to the test case introduced in the next commit, this new description was tested by focusing fuzzing on bpf_trace_printk. That is, a new syscall description PROG_LOAD_FOCUS was added to cover only programs with bpf_trace_printk. Syzkaller was then executed on 16 VMs (2 logical cores each) with only the bpf$PROG_LOAD_FOCUS and bpf$BPF_PROG_TEST_RUN syscalls enabled. It was able to reach the definition of this helper [1] within a few minutes. 1 - https://github.com/torvalds/linux/blob/v6.5/kernel/trace/bpf_trace.c#L375 Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: templatize ldst, alu, and call_helper BPF instructionsPaul Chaignon2023-10-161-22/+34
| | | | | | | | | | | | | | This commit templatizes the bpf_insn_ldst, bpf_insn_alu, bpf_insn_call_helper, bpf_insn_map_value BPF instruction descriptions. This will allow subsequent commits to define new, more specific descriptions of those instructions in addition to the existing generic descriptions. For example, a subsequent commit will use the new bpf_insn_call_helper_t template to define a call to helper bpf_snprintf specifically. This commit doesn't have any functional changes. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: templatize arg for BPF_MAP_CREATEPaul Chaignon2023-10-161-23/+9
| | | | | | | | | | | This templatization of bpf_map_create_arg_base enables a less verbose way to define map type-specific arguments. It can already be used for maps of type BPF_MAP_TYPE_BLOOM_FILTER and will be used for maps holding constant strings in a subsequent commit. This commit doesn't have any functional changes. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: mark optional BPF_PROG_LOAD arguments as optPaul Chaignon2023-10-051-2/+2
| | | | | | | func_info and line_info are both optional and should be marked as such. Fixes: 934bb8cadebb57 ("modify") Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: fix include lines and regenerate constsAleksandr Nogikh2023-10-041-0/+1
| | | | Some includes got obsolete over time.
* sys/linux: cover multi-uprobes for BPF_LINK_CREATEPaul Chaignon2023-09-131-0/+12
| | | | | | | | | | | | | | | Upstream, commit [1] added support for multi-uprobe links, to speed up the attachment of uprobes BPF programs by attaching in batches. This commit covers the same in syzkaller. Field path is a path to the binary, offsets are the offsets to attach to in the binary, and cnt is the number of uprobes to attach to. Field ref_ctr_offsets is a bit trickier as it can point to an array of reference counters; I limited those to 0--5 as they are not expected to be large. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=89ae89f53d2011435 Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: cover tcx attachment for BPF_LINK_CREATEPaul Chaignon2023-09-131-0/+6
| | | | | | | | | | Commit [1] upstream added support for tcx program attachment through BPF_LINK_CREATE. This commit covers the UAPI extension for that command in syzkaller. It reuses the id_or_fd union defined in commit ece90fe7b89e ("sys/linux: support multi-progs for BPF_PROG_ATTACH"). 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e420bed025071a62 Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: cover BPF links for BPF netfilter programsPaul Chaignon2023-09-131-0/+10
| | | | | | | | | Commit [1] upstream added support for attaching BPF netfilter programs through the BPF_LINK_CREATE bpf(2) command. This commit adds the syzkaller counterpart. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=84601d6ee68ae820d Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: cover cookie for tracing BPF linksPaul Chaignon2023-09-131-0/+6
| | | | | | | | | Commit [1] added the ability to pass a cookie at BPF link creation time for many tracing program types. This commit covers the same in syzkaller. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2fcc82411e74e5e6a Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: cover multi-kprobes in BPF_LINK_CREATEPaul Chaignon2023-09-131-0/+23
| | | | | | | | | | | | | | Commit [1] upstream added support for multi-kprobes to BPF link, to allow attaching many kprobes BPF programs at once. In doing so, the BPF_LINK_CREATE command was extended with attachment information for kprobes. This commit covers this in syzkaller's description. We have two cases to cover: kprobes are either attached by symbols (resolved by the kernel) or directly by kernel addresses. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0dcac272540613d41 Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: cover perf cookie in BPF_LINK_CREATEPaul Chaignon2023-09-131-0/+5
| | | | | | | | Commit [1] extended bpf(2) BPF_LINK_CREATE to allow userspace to pass an opaque cookie number for perf BPF links. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=82e6b1eee6a8875ef Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: cover BPF iterators support in BPF_LINK_CREATEPaul Chaignon2023-09-131-0/+30
| | | | | | | | | | | | | | | | Commit [1] upstream extended the bpf(2) BPF_LINK_CREATE command with optional fields for BPF iterators. The extra field is a pointer to a bpf_iter_link_info struct and its size. Commits [2, 3] upstream latter extended the bpf_iter_link_info struct to cover cgroup and task iterators. This commit extends the syzkaller description of BPF_LINK_CREATE to cover the above. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5e7b30205cef80f6b 2 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4ccaf58a8472123a 3 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f0d74c4da1f060d2a Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: support multi-progs for BPF_PROG_QUERYPaul Chaignon2023-09-111-4/+9
| | | | | | | | | | | | Commit [1] upstream, and subsequent patches, extended the BPF_PROG_QUERY command to support a new multi-prog object in the BPF subsystem. In particular the command can now dump the link IDs and the link attach flags. It is also the only way currently to retrieve the revision number of a BPF program (for use in BPF_PROG_{ATTACH,DETACH} commands). 1 - 053c8e1f235dc ("bpf: Add generic attach/detach/query API for multi-progs") Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: support multi-progs for BPF_PROG_DETACHPaul Chaignon2023-09-111-4/+8
| | | | | | | | | | | | Commit [1] upstream, and subsequent patches, extended the BPF_PROG_DETACH command to support a new multi-prog object in the BPF subsystem. It now supports the same fields as its BPF_PROG_ATTACH, with one exception, replace_bpf_fd, which must stay NULL. The reference to the relative object is supported, as well as the expected revision number and a set of flags. 1 - 053c8e1f235dc ("bpf: Add generic attach/detach/query API for multi-progs") Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: support multi-progs for BPF_PROG_ATTACHPaul Chaignon2023-09-111-1/+11
| | | | | | | | | | | | | | Commit [1] upstream, and subsequent patches, extended the BPF_PROG_ATTACH command to support a new multi-prog object in the BPF subsystem. In particular, programs can now be attached relative to another object (relative_obj), a BPF program or link, referenced via either an fd or a BPF ID (id_or_fd). In addition, a new concept of BPF revision number was introduced and a revision number can be passed, to be checked at attach time. Finally, the attachment target can now also be an ifindex. 1 - 053c8e1f235dc ("bpf: Add generic attach/detach/query API for multi-progs") Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: update BPF constantsPaul Chaignon2023-09-111-4/+4
| | | | Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: add more coverage for MPTCPChristoph Paasch2023-09-041-1/+1
| | | | | | New netlink command has been added to MPTCP as well as a few getsockopt. Add the necessary syskaller instructions.
* sys/linux: support btf_log_true_size field for BPF_BTF_LOADPaul Chaignon2023-08-251-5/+6
| | | | | | | Support the new field defined upstream in commit [1]. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=47a71c1f9af0 Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: support prog_attach_flags field for BPF_PROG_QUERYPaul Chaignon2023-08-251-6/+7
| | | | | | | | | Commit [1] upstream added a new field to the anonymous struct for the BPF_PROG_QUERY bpf(2) command, for the kernel to return the attach flags of the program. This commit adds this field in the syzkaller struct. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b79c9fc9551b Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* sys/linux: support O_PATH fds in BPF_OBJ_* cmdsPaul Chaignon2023-08-251-3/+44
| | | | | | | | | | | | Commit [1] upstream added support for O_PATH fds in BPF_OBJ_* commands. This commit implements the same support in syzkaller. The flag BPF_F_PATH_FD must be set when passing an O_PATH to the BPF_OBJ_* commands. We therefore declare generic and O_PATH-specific variants of the existing BPF_OBJ structs. 1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb8edce2807 Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
generated by ggit (джигит) mrf-deployment (git 2.46.0) at 2026-03-12 01:11:33 +0000