| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
Any is the preferred over interface{} now in Go.
|
| |
|
|
|
|
|
|
| |
Ensure that corpus and signal are non-zero after the bugs have been
found.
Fix coverage configuration - the test was de facto running on a fallback
coverage.
|
| |
|
|
|
| |
Accept context as a function argument.
Split out the code that creates a syz-executor process instance.
|
| |
|
|
| |
It should hopefully let us debug #5674.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we can get either:
WARNING: DATA RACE
Read at 0x00c0018fe1e0 by goroutine 11:
github.com/google/syzkaller/pkg/fuzzer.(*testFuzzer).run()
pkg/fuzzer/fuzzer_test.go:183 +0x62a
github.com/google/syzkaller/pkg/fuzzer.TestFuzz()
pkg/fuzzer/fuzzer_test.go:86 +0xa96
testing.tRunner()
testing/testing.go:1595 +0x238
testing.(*T).Run.func1()
testing/testing.go:1648 +0x44
Previous write at 0x00c0018fe1e0 by goroutine 36:
runtime.mapassign_faststr()
runtime/map_faststr.go:203 +0x0
github.com/google/syzkaller/pkg/fuzzer.(*testFuzzer).OnDone()
pkg/fuzzer/fuzzer_test.go:210 +0x404
github.com/google/syzkaller/pkg/fuzzer.(*testFuzzer).OnDone-fm()
<autogenerated>:1 +0x47
github.com/google/syzkaller/pkg/fuzzer.(*testFuzzer).Next.(*Request).OnDone.func1()
pkg/fuzzer/queue/queue.go:62 +0xa1
github.com/google/syzkaller/pkg/fuzzer/queue.(*retryer).Next.(*Request).OnDone.func1()
pkg/fuzzer/queue/queue.go:68 +0xbe
github.com/google/syzkaller/pkg/fuzzer/queue.(*Request).Done()
pkg/fuzzer/queue/queue.go:74 +0x66
github.com/google/syzkaller/pkg/rpcserver.(*Runner).handleExecResult()
pkg/rpcserver/runner.go:262 +0x554
github.com/google/syzkaller/pkg/rpcserver.(*Runner).connectionLoop()
pkg/rpcserver/runner.go:103 +0x495
github.com/google/syzkaller/pkg/rpcserver.(*Server).connectionLoop()
pkg/rpcserver/rpcserver.go:371 +0x18a
github.com/google/syzkaller/pkg/rpcserver.(*Server).handleConn()
pkg/rpcserver/rpcserver.go:261 +0x6ac
github.com/google/syzkaller/pkg/rpcserver.(*Server).handleConn-fm()
<autogenerated>:1 +0x3d
github.com/google/syzkaller/pkg/flatrpc.ListenAndServe.func1.1()
pkg/flatrpc/conn.go:54 +0x2ac
Or:
panic: Log in goroutine after TestFuzz has completed: CRASH: second bug
goroutine 69 [running]:
testing.(*common).logDepth(0xc0017c24e0, {0xc00070c0d8, 0x11}, 0x3)
testing/testing.go:1029 +0x6d4
testing.(*common).log(...)
testing/testing.go:1011
testing.(*common).Logf(0xc0017c24e0, {0x1365b2d, 0x9}, {0xc001aac930, 0x1, 0x1})
testing/testing.go:1062 +0xa5
github.com/google/syzkaller/pkg/fuzzer.(*testFuzzer).OnDone(0xc001a222a0, 0x10ace5d?, 0xc00073c870)
pkg/fuzzer/fuzzer_test.go:205 +0x23a
github.com/google/syzkaller/pkg/fuzzer.(*testFuzzer).Next.(*Request).OnDone.func1(0xc004745080, 0xc00073c870)
pkg/fuzzer/queue/queue.go:72 +0xa8
github.com/google/syzkaller/pkg/fuzzer/queue.(*retryer).Next.(*Request).OnDone.func1(0xc004745080, 0xc00073c870)
pkg/fuzzer/queue/queue.go:78 +0xc5
github.com/google/syzkaller/pkg/fuzzer/queue.(*Request).Done(0xc004745080, 0xc00073c870)
pkg/fuzzer/queue/queue.go:84 +0x74
github.com/google/syzkaller/pkg/rpcserver.(*Runner).handleExecResult(0xc0019ec000, 0xc00072bbc0)
pkg/rpcserver/runner.go:265 +0x5b5
github.com/google/syzkaller/pkg/rpcserver.(*Runner).connectionLoop(0xc0019ec000)
/home/dvyukov/go/src/github
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Move all syz-fuzzer logic into syz-executor and remove syz-fuzzer.
Also restore syz-runtest functionality in the manager.
Update #4917 (sets most signal handlers to SIG_IGN)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
Switch to flatrpc.ExecOpts.
|
| |
|
|
|
|
| |
Switch to flatrpc.ProgInfo.
Note: this disables syz-runtest and syz-verifier.
|
| |
|
|
|
|
| |
Flatrpc flags are passed in RPC execution requests,
so to avoid conversions and duplicate set of flags
use flatrpc flags in pkg/ipc directly.
|
| |
|
|
| |
There's no need in duplicating the signal, coverage, hints flags.
|
| |
|
|
|
|
| |
Make Result statuses more elaborate.
Instead of retrying inputs directly in rpc.go, extract this logic to a
separate entity in pkg/fuzzer/queue.
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead of relying on a fuzzer-internal priority queue, utilize
stackable layers of request-generating steps.
Move the functionality to a separate pkg/fuzzer/queue package.
The pkg/fuzzer/queue package can be reused to add extra processing
layers on top of the fuzzing and to combine machine checking and fuzzing
execution pipelines.
|
| | |
|
| |
|
|
|
|
| |
Now that manager sends ipc.ExecOpts to the fuzzer,
there is no point in having Signal type in rpctype.
It belongs to pkg/fuzzer.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pass EnvFlags into Exec instead of New.
This allows to change EnvFlags between executions.
Change of EnvFlags forces executor process restart
since it uses EnvFlags during setup.
Currently this is intended to be NFC since we always
pass the same EnvFlags.
In future this will allow to (1) reduce part of the
VM checking procedure to execution of programs with
different options (e.g. we can probe for coverage/comparisons
support, probe different sandboxes, etc);
(2) use it during fuzzing/reproduction, e.g. we can check
if the crash reproduces under setuid sandbox, or execute some
fuzzing programs in significantly different modes.
|
| |
|
|
|
|
|
| |
Add ability for each package to create and export own stats.
Each stat is self-contained, describes how it should be presented,
and there is not need to copy them from one package to another.
Stats also keep historical data and allow building graphs over time.
|
| |
|
|
|
| |
OpenBSD in particular is not compatible with TestOS expectation
of having a syscall function.
|
| |
|
|
|
| |
Demand that at least 3 out of 5 runs share common signal.
Exit early if it's not feasible.
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
This functionality will soon be deleted. Rely on the Corpus object
updates.
|
| |
|
|
|
| |
Stats() seems to be a more sound choice since these structures include
multiple data points.
|
| |
|
|
|
|
|
|
| |
pkg/fuzzer and syz-manager have a common corpus functionality that can
be well be unified.
Create a separate pkg/corpus package that would be used by both of them.
It will simplify further work of moving pkg/fuzzer to the host.
|
|
|
This is the first step for #1541.
Move the fuzzing engine that used to be interleaved with other syz-fuzzer
code into a separate package.
For now, the algorithm is more or less the same as it was, the only
difference is that a pkg/fuzzer instance scales to the available
computing power.
Add an executor-based test that performs real fuzzing.
|