| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Any is the preferred over interface{} now in Go.
|
| | |
|
| |
|
|
| |
They are shorter, more readable, and don't require temp vars.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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 long runs, it can be thousands of points for every single graph
that we render. It's much more than is actually needed.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
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.
|
