| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Any is the preferred over interface{} now in Go.
|
| |
|
|
|
| |
Check for the existence of fsck binaries and report their absence only
once.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of generating Go files with descriptions
serialize them as gob and compress with flate.
This significantly reduces build time, go vet time,
and solves scalability problems with some static analysis tools.
Reference times (all after rm -rf ~/.cache/go-build) before:
TIME="%e %P %M" time go install ./syz-manager
48.29 577% 4824820
TIME="%e %P %M" time go test -c ./prog
56.28 380% 6973292
After:
TIME="%e %P %M" time go install ./syz-manager
22.81 865% 859788
TIME="%e %P %M" time go test -c ./prog
12.74 565% 267760
syz-manager size before/after: 194712597 -> 83418407
-57% even provided we now embed all descriptions
instead of just a single arch.
Deflate/decoding time for a single Linux arch is ~330ms.
Fixes #5542
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
My dev environment skips the osutil_linux sandbox because it doesn't
have a "syzkaller" user and group. The CI environment also skips the
sandbox because it sets the "CI" environment variable.
Therefore, nothing caught that, when run in the syzbot docker container,
(which has a "syzkaller" user) the sandbox actually starts to be used
and breaks fsck commands.
Syz-manager, which is run as root, writes the image to /tmp/1234.img
with permissions 0600 and then tries to run fsck under the "syzkaller"
user which doesn't have read permissions on the file, so fsck fails:
fsck.ext4 -n exited with status code 8
e2fsck 1.47.0 (5-Feb-2023)
fsck.ext4: Permission denied while trying to open /tmp/1234.img
You must have r/o access to the filesystem or be root
Changing the owner of the file to the "syzkaller" user before attempting
to run fsck under that user fixes the problem.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Syscall attributes are extended with a fsck command field which lets
file system mount definitions specify a fsck-like command to run. This
is required because all file systems have a custom fsck command
invokation style.
When uploading a compressed image asset to the dashboard, syz-manager
also runs the fsck command and logs its output over the dashapi.
The dashboard logs these fsck logs into the database.
This has been requested by fs maintainer Ted Tso who would like to
quickly understand whether a filesystem is corrupted or not before
looking at a reproducer in more details. Ultimately, this could be used
as an early triage sign to determine whether a bug is obviously
critical.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
When we decompress images for mutation or hints,
we always specially check for empty compressed data
(I assume it can apper after minimization).
Treat it as correct compressed and return empty decompressed data.
This removes the need in special handling in users.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Benchmark results:
name old time/op new time/op delta
Decompress-8 24.7ms ± 1% 13.4ms ± 4% -45.81% (p=0.000 n=16+19)
name old alloc/op new alloc/op delta
Decompress-8 67.2MB ± 0% 0.0MB ± 1% -99.98% (p=0.000 n=18+20)
name old allocs/op new allocs/op delta
Decompress-8 188 ± 0% 167 ± 0% -11.17% (p=0.000 n=20+20)
Test process memory consumption drops from 220MB to 80MB.
|
| |
|
|
|
|
|
|
|
|
| |
Change DecompressWriter to DecompressCheck: checking validity
of the image is the only useful use of DecompressWriter.
Change Decompress to MustDecompress which does not return an error.
We check validity during program deserialization, so all other
uses already panic on errors.
Also add dtor return value in preparation for subsequent changes.
|
|
|
Move image compression-related function to a separate package.
In preperation for subsequent changes that make decompression
more complex. Prog package is already large and complex.
Also makes running compression tests/benchmarks much faster.
|
