| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Any is the preferred over interface{} now in Go.
|
| | |
|
| |
|
|
|
|
|
|
| |
filepath.Walk calls os.Lstat for every file or directory to retrieve os.FileInfo.
filepath.WalkDir avoids unnecessary system calls since it provides a fs.DirEntry,
which includes file type information without requiring a stat call.
This improves performance by reducing redundant system calls.
|
| |
|
|
| |
They are shorter, more readable, and don't require temp vars.
|
| |
|
|
| |
Fix inconsistent HTML file formatting with both tabs and spaces.
|
| |
|
|
|
|
| |
It reduces the size of the syz-manager/ code and makes it testable.
Use it in syz-testbed.
|
| |
|
|
|
|
|
|
| |
Go package names should generally be singular form:
https://go.dev/blog/package-names
https://rakyll.org/style-packages
https://groups.google.com/g/golang-nuts/c/buBwLar1gNw
|
| |
|
|
|
| |
This will reduce the number of dependencies needed for the main
syzkaller tools.
|
| |
|
|
|
|
|
|
| |
Add corpus triage mode and support it in testbed.
This is useful to benchmark just the triage phase
w/o any subsequent fuzzing. First, fuzzing is more random.
Second, if triage duration is different in different versions,
then they will do different amount of fuzzing in fixed testbed time.
|
| |
|
|
|
| |
This is useful if instances run for different amount of time.
It's hard to make any sense out of aligned records in that case.
|
| |
|
|
| |
In case it's installed.
|
| | |
|
| |
|
|
|
| |
In long runs, it can be thousands of points for every single graph
that we render. It's much more than is actually needed.
|
| |
|
|
|
|
|
|
| |
If the column value is not present, but compute relative value changes,
we still need to add two cells.
Also, there's no need in the PrintValue template -- the String() method
does the same computation.
|
| |
|
|
|
| |
It's perfectly normal for a column value not to be present -- e.g. when
we compare syzkaller branches that don't use the same statistics.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
It's more correct to evaluate whether we managed to reproduce the
original bug rather than just any bug.
Retrieve the title information from syz-repro and pretent that the
reproduction failed if the title does not match.
|
| |
|
|
|
| |
Move functions that need embed assets to a separate package.
In preparation for the next change.
|
| | |
|
| |
|
|
|
|
|
| |
Add a "syz-repro" target and 3 tables:
- List of all performed (and ongoing) reproductions.
- Comparison of repro rate for different bugs on different checkouts.
- Comparison of the share of C reproducers.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor the code of syz-testbed to enable support of different targets.
This required the following changes:
- Instead of doing mass start and mass restart of instances, let them be
more independent.
- Support different types of instances, which may have different
expectations of the target behavior. E.g. syz-manager normally never
exits, while syz-repro is expected to exit after a certain time.
- Factor out stats management, as stat entries may be different for
different targets.
- Introduce locking to TestbedCtx and Checkout, as slices there can be
modified at arbitrary times.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Otherwise there's a risk that the instance is stopped before Run() has
had a chance to be executed. This leads to a panic while doing
cmd.Signal().
|
| |
|
|
|
|
|
|
|
|
| |
It's not practical to parse configs from tools/syz-testbed because it
limits the tool to using only those configuration options, which are
supported by the syzkaller version at the moment of tools/syz-testbed
compilation.
Operate with manager configs as if they were just some JSON objects.
Introduce a PatchJSON method to update their fields in a convenient way.
|
| |
|
|
| |
Make it easier to do uiTableType filtering later.
|
| | |
|
| |
|
|
|
| |
This table does not just collect YES/NO, but also shows the number of
test runs in which syz-manager has discovered the given bug.
|
| |
|
|
|
|
|
|
|
| |
Formalise HTML table management - introduce the map, which lists the
available stat tables and their generators.
Render only one page at a time and let the user switch them.
Implement the generation of the bug table.
|
| |
|
|
|
|
| |
Otherwise the page is requested two times by Chrome.
See https://bugs.chromium.org/p/chromium/issues/detail?id=39402
|
| |
|
|
|
|
|
|
|
|
| |
It turns out that we often want to see the data aligned on some specific
property - e.g. align all checkouts by "exec total" and see how other
parameters differ.
Add a preliminary support of such a feature. On a row title click, pick
the minimal value in the row and wind the history of each column back
until the target row value is closest to the minimal one.
|
| |
|
|
|
|
|
|
|
|
| |
Enable the user to specify the pivot column for the stats table. If
such a column is set, calculate and print the relative difference
between checkouts and p-values for the estimation of statistical
significance of the experimental data.
For the p-value calculation use the existing implementation from the
go-benchstat tool.
|
| |
|
|
|
| |
In the HTML form, show only one stat view at a time. Let user switch
between the views.
|
| |
|
|
|
| |
This simplifies table generation and will let us more easily implement
relative difference and p-value calculation and printing.
|
| |
|
|
|
|
|
| |
Data generated in experiments indicates that the distribution for most
(all?) syzkaller parameters is not perfectly normal - it is skewed and
there are many outliers. Median seems like a more adequate statistic in
this case.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let the user of the tool specify individual syz-manager configs for
checkouts. A base config is specified as previously and then individual
parts of jsons are applied to that base config, e.g.
<...>
"checkouts": [
{
"name": "first",
"repo": "https://github.com/google/syzkaller.git",
},
{
"name": "second",
"repo": "https://github.com/google/syzkaller.git",
"manager_config": {
"kernel_obj": "/tmp/linux-stable2"
}
}
],
"manager_config": {
"target": "linux/amd64",
"kernel_obj": "/tmp/linux-stable",
<...>
}
<...>
|
| |
|
|
|
|
|
|
|
|
| |
If `max_instances` is smaller than the total number of checkouts in the
testbed configuration file, the averaged per checkout statistics was
inconsistend with respect to the point in time. Checkouts with running
instances were winded back to the current uptime, while others used to
show the complete data.
Fix that inconsistency.
|
| |
|
|
| |
For now, just display the avg stats and generate graphs on demand.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Creation of instances only at the start of the tool limits the scale of
the experiments.
Instead of setting up instances at the beginning, create, start and
stop them dynamically. This allows to conduct much larger experiments
while keeping the maximal resource consuption under control. When an
instance has been executing for the specified time, it is stopped and
replaced by another one.
Introduce two new parameters:
- max_instances - the maximal number of simultaneously running instances.
- run_hours - the lifetime (in hours) of a single instance.
The longer the tool runs, the more test results will be accumulated for
each checkout specified in the configuration file.
|
| | |
|
| |
|
|
|
| |
Doing so can result in syz-manager leaking GCE instances. Set PDEATHSIG
to SIGTERM instead, so that syz-manager has a change to exit gracefully.
|
|
|
The tool automates check-out, compilation, config generation and a
simultaneous startup of a number of syz-manager instances.
Also, it can collect and output the combined statistics from these
managers in order to simplify further analysis of the results.
|
