Branch: refs/heads/gh-readonly-queue/master/pr-4312-8b88555225e877e51e8cbc9a90c30f315525dde6
Home:
https://github.com/google/syzkaller
Commit: 46390d8e7dd2127b50fab99fee4467aca46ab28c
https://github.com/google/syzkaller/commit/46390d8e7dd2127b50fab99fee4467aca46ab28c
Author: Paul Chaignon <
paul.c...@gmail.com>
Date: 2023-11-06 (Mon, 06 Nov 2023)
Changed paths:
M sys/linux/bpf.txt
Log Message:
-----------
sys/linux: describe BPF tail call map
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.c...@gmail.com>
Commit: b1547b1e6ffceaa58562db48077ea5588372eacd
https://github.com/google/syzkaller/commit/b1547b1e6ffceaa58562db48077ea5588372eacd
Author: Paul Chaignon <
paul.c...@gmail.com>
Date: 2023-11-06 (Mon, 06 Nov 2023)
Changed paths:
M sys/linux/bpf.txt
M sys/linux/bpf.txt.const
Log Message:
-----------
sys/linux: describe call to bpf_tail_call helper
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.c...@gmail.com>
Commit: 8321139737ed27c82617231b782e88dd1e818227
https://github.com/google/syzkaller/commit/8321139737ed27c82617231b782e88dd1e818227
Author: Paul Chaignon <
paul.c...@gmail.com>
Date: 2023-11-06 (Mon, 06 Nov 2023)
Changed paths:
M sys/linux/test/bpf_helpers
Log Message:
-----------
sys/linux/test: test case for bpf_tail_call helper
This test case corresponds to the BPF program below (bcc syntax for the
map).
BPF_PROG_ARRAY(prog_array, 10);
int tail_call_prog(void *ctx) {
char str[8] = {0};
u64 data = 0x1234;
bpf_snprintf(str, sizeof(str), "%d ", &data, sizeof(data));
return 0;
}
int do_tail_call(void *ctx) {
prog_array.call(ctx, 0);
return 0;
}
It reuses the program defined to test bpf_snprintf, as the target of the
tail call.
Signed-off-by: Paul Chaignon <
paul.c...@gmail.com>
Compare:
https://github.com/google/syzkaller/compare/46390d8e7dd2%5E...8321139737ed