| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Test that if we enable only auto descriptions, nothing gets disabled.
Currently nothing can create fd_cgroup which is used by the descriptions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tests sometimes fail as:
--- FAIL: TestCreateResourceRotation (0.97s)
...
resources_test.go:181: testing call syz_io_uring_submit
resources_test.go:187: failed to create resource fd_dir
FAIL
Almost always it's related to fd_dir resource.
The problem is with no_generate syscalls (we have lots of
no_generate mount syscalls that produce fd_dif).
Rotator considers them as legit resource ctors,
but the actual code in createResource does not.
As the result Rotator creates subsets of syscalls
where not all resources can be created.
The same problem affects TransitivelyEnabledCalls.
It may leave syscalls that require resources produced only
by no_generate syscalls. We won't be able to produce such
resources during fuzzing.
Split Syscall.outputResources to createResources
(can actually be used to create, excludes no_generate)
and usesResources, this includes no_generate syscalls.
|
| |
|
|
|
|
| |
Print better message and print it when verbosity >= 1.
This will allow to easier diff any changes in enabled
syscalls caused by future code changes.
|
| |
|
|
| |
They used to depend on the side effects of BuildChoiceTable().
|
| |
|
|
|
|
|
|
|
| |
If no matching resource was already present in the program, we used to
substitute a random value in ~50% of cases. That's not efficient.
Restructure the resource generation process so that, if there are no
other options, we generate a new resource in 80% cases and in the
remaining 20% we substitute an integer.
|
| |
|
|
|
|
|
|
|
|
| |
During resource argument generation, we used to randomly select one of
the matching resources. With so many descendants of fd, this becomes
quite inefficient and most of the time syzkaller fails to build correct
programs.
Give precise resource contructions priority. Experiment with other
resource types only in 1/3 of cases.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds more complex unit tests to cover the bug in
getInputResources fixed by the previous commit.
required_res1 and test_args3 covers the case where a struct is included
both as optional and required. required_res2 and test_args4 cover the
case where a struct is included both as DirOut and DirIn. In both cases
the resource should be recognized as being a required input resource for
the syscall.
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
|
| |
|
|
|
|
|
|
|
|
| |
This commit adds a unit test for getInputResources, to verify in
particular that it doesn't return input resources that are optional.
Note we can't test the built-in "optional[]" because that relies on
unions and those aren't supported yet.
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If trying to fuzz only bpf$PROG_LOAD, the executors fail with:
SYZFATAL: Manager.Check call failed: machine check failed: all
system calls are disabled
That is happening because it detects a dependency on fd_bpf_map via two
paths:
1. bpf_prog_t.fd_array is an optional pointer to an array of fd_bpf_map.
2. The bpf_insn union contains descriptions for two instructions,
bpf_insn_map_fd and bpf_insn_map_value, that reference fd_bpf_map.
Both of those cases point to optional uses of fd_bpf_map, but syzkaller
isn't able to recognize that today.
This commit addresses the first case, when a resource or one of the
types using it are explicitly marked as optional. Before this commit,
syzkaller was only able to recognize the case where the resource itself
is marked as optional. However, in the case of e.g. bpf_prog_t.fd_array,
it's the pointer to the array of fd_bpf_map that is marked optional.
To fix this, we propagate the optional bit when walking down the AST. We
then pass this propagated bit to the callback function via the context.
This change was tested on the above bpf$PROG_LOAD case 1, by removing
bpf_insn_map_fd and bpf_insn_map_value from the bpf(2) description to
avoid hitting case 2. Addressing case 2 will require more changes to the
same logic.
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currnetly we loop up to 1000 times in randGen.createResource,
this is necessary because we can't guarantee that the generated syscall
will indeed contain the necessary resources. This is ugly.
Now that we have stricter constructors (no unions) with few additional tweaks
we can guarantee that we generate the resource every time.
Generate at least 1 array element when in createResource.
Don't generate special empty pointers when in createResource.
Record only resource constructors in Syscall.outputResource,
this makes rotation logic to include at least 1 of them.
|
|
|
decl_test.go is some legacy. We don't have decl.go
The file contains tests for resources and code contained
in resources.go, so rename it to resources_test.go.
|
