| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Any is the preferred over interface{} now in Go.
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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",
<...>
}
<...>
|
|
|
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.
|
