| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
| |
Any is the preferred over interface{} now in Go.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Signal rotation is intended to make the fuzzer re-discover flaky coverage
in non flaky way. However, taking into accout that we get effectively
the same effect after each manager restart, and that the fuzzer is overloaded
with triage/smash jobs, it does not look to be worth it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Taken some arm64 devices for example:
kaslr_offset is diff at bits 12-40, and kernel modules are loaded at 2GB space,
so we have `ffffffd342e10000 T _stext` where uppper 32bit is ffffffd3. However,
if we check modules range, the 1st module is loaded at 0xffffffd2eeb2a000,
while the last module is loaded at 0xffffffd2f42c4000.
We can see the upper 32bits are diff for core kernel and modules.
If we use current 32bits for covered PC, we will get wrong module address
recovered.
So we need to move to 64bit cover and signal:
- change cover/sig to 64bit to fit for syz-executor change
- remove kernel upper base logic as kernel upper base is not a constant when
kaslr enabled for core kernel and modules.
- remove unused pcBase
|
| |
|
|
|
|
|
|
|
|
|
| |
This fixes 2 issues:
1. We still want to get new coverage for syscalls during minimization.
We run lots of new programs, and some of them can give new coverage.
2. The signal filter should apply only to the target syscall.
Other syscalls probably can't even reach any of that code.
So add SignalFilterCall field and combine new and filtered signal
for that call. Other calls just collect new coverage as usual.
|
| |
|
|
|
|
| |
We don't want to reach just any stable signal, we know the specific new
signal that we target. The previous approach might have reduced the
efficiency of the new deflake() approach.
|
| |
|
|
|
|
|
| |
Once in 15 minutes, drop 1000 elements of the pure max signal (that is,
max signal minus corpus signal).
It seems to have a positive effect on the total fuzzing performance.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Instead of doing fuzzing in parallel in running VM, make all decisions
in the host syz-manager process.
Instantiate and keep a fuzzer.Fuzzer object in syz-manager and update
the RPC between syz-manager and syz-fuzzer to exchange exact programs to
execute and their resulting signal and coverage.
To optimize the networking traffic, exchange mostly only the difference
between the known max signal and the detected signal.
|
| |
|
|
|
| |
If all signal is to be returned to the caller, there's no sense in
deleting it from the original map. Just swap it.
|
| |
|
|
|
|
|
|
| |
Addresses https://github.com/google/syzkaller/issues/4078
Does not fix canonicalization when modules change over time, but
does unblock fuzzing by avoiding a kernel panic when modules
change.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Adjust signal creation in syz-executor so hash
is independent of module offsets. This allows
for canonicalization of the signal between VMs.
Added signals to canonicalization/decanonicalization
between instances.
Coverts serialized Signal values as they have already
been serialized in rpc.go. Added a function in signal.go
to update serial signal elements.
|
| |
|
|
|
|
|
|
|
| |
Use a random subset of syscalls/corpus/coverage for each individual VM run.
Hypothesis is that this should allow fuzzer to get more coverage
find more bugs in saturated state (stuck in local optimum).
See the issue and comments for details.
Update #1348
|
| |
|
|
|
| |
Also mixin resource constructors and some signature
of flags values for successful calls into fallback coverage.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
RPC package does excessive caching per connection,
so if a larger object is ever sent in any direction,
rpc connection consumes large amount of memory persistently.
This makes manager consume gigs of memory with large
number of VMs and larger corpus/coverage.
Make all communication done in very limited batches.
|
| |
|
|
| |
Fix typos, non-canonical code, remove dead code, etc.
|
|
|
Signal on successful syscalls is more valuable than
signal on unsuccessful syscalls.y
|
