| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
| |
These occurences were found with the command:
git grep -lP "{(AUTO,\s)*AUTO}"
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
| |
Commit [1] upstream added a new field to the bpf(2) PROG_LOAD command
for the kernel to return the buffer size that would be required to store
all logs. This is an output-only field so probably not much point in
fuzzing it, so let's fix it to 0.
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>
|
| |
|
|
|
|
|
|
|
|
| |
Commit [1] upstream added support via the bpf(2) PROG_LOAD command to
load BTF CO-RE relocation data. This commit adds basic support for
loading the same data in syzkaller. As usual with BTF, we are pretty
limited in what we can efficiently describe :-(
1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fbd94c7afcf9
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit [1] upstream introduced a new way to reference BPF maps in eBPF
instructions. An array of BPF map fds is passed at program load time.
Instructions can then reference fds in this array instead of carrying
the fds directly. The goal is to allow BPF instructions to be immutable
after compilation.
Since we don't yet have a good way to reference indexes in an array, we
define a new type map_fd_id for that purpose, with indexes between 0 and
16 only.
1 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=387544bfa291
Signed-off-by: Paul Chaignon <paul@isovalent.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Represent array[const[X, int8], N] as string["XX...X"].
This replaces potentially huge number of:
NONFAILING(*(uint8_t*)0x2000126c = 0);
NONFAILING(*(uint8_t*)0x2000126d = 0);
NONFAILING(*(uint8_t*)0x2000126e = 0);
with a single memcpy. In one reproducer we had 3991 such lines.
Also replace memcpy's with memset's when possible.
Update #1070
|
|
|
- Add a test for BPF_PROG_TYPE_CGROUP_SYSCTL. This could be used as a
corpus.
- Remove an unnecessary file sys/linux/bpf_lsm.txt.const.
|
