You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+3
Original file line number
Diff line number
Diff line change
@@ -12,6 +12,8 @@
12
12
### Upgrading from an Earlier Release of VMF?
13
13
See [migration-4.0.0.md](docs/migration-4.0.0.md) for a list of the API changes in VMF 4.0.0.
14
14
15
+
***Note: VMF is compatible with compiler instrumentation from AFL++ 4.10c or earlier, due to an update in the forkserver interface that was introduced in 4.20c. VMF will be updated in a future release to fix this compatibility issue.***
16
+
15
17
### VMF Compatibility
16
18
17
19
As of now, VMF can be run in Docker and on the following distributions of Linux:
@@ -23,6 +25,7 @@ As of now, VMF can be run in Docker and on the following distributions of Linux:
23
25
- Ubuntu 20.04, and 22.04
24
26
25
27
VMF depends on several open source projects, but uses a "batteries-included" philosophy to dependencies where practical.
28
+
26
29
The sources of particular versions of these dependencies live inside of the VMF tree.
27
30
For more information about VMF's included package, and other required dependencies, see
Copy file name to clipboardExpand all lines: docs/configuration.md
+3-1
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
3
3
## Introduction
4
4
5
-
The VMF configuration file is contained in one or more YAML file. These YAML files provides a structure to the configuration of the fuzzer and its modules. Each top level YAML section (i.e. `vmfFramework`) must be contained within a single file, but otherwise the configuration parameters may be split into multiple files, as desired. Note that all of the examples provided with VMF put the System Under Test (SUT) specific parameters into one file, and the other configuration sections in a second file. See [getting_started.md](/docs/getting_started.md) for more information on our example configuration files and their organization.
5
+
The VMF configuration file is contained in one or more YAML file. These YAML files provides a structure to the configuration of the fuzzer and its modules. Each top level YAML section (i.e. `vmfFramework`) must be contained within a single file, but otherwise the configuration parameters may be split into multiple files, as desired. Note that all of the examples provided with VMF put the System Under Test (SUT) specific parameters into one file, and the other configuration sections in a second file. See [getting_started.md](getting_started.md) for more information on our example configuration files and their organization.
Configuration information specific to the ComputeStats module, which computes statistics using the information in storage.
540
+
541
+
### `ComputeStats.statsRateInSeconds`
542
+
543
+
Value type: `<int>`
544
+
545
+
Status: Optional
546
+
547
+
Default value: 1
548
+
549
+
Usage: This parameter specifies how often the module should compute statistics, in seconds. Note that a few of the total test case statistics have to be counted on every pass through the fuzzing loop, because they rely on directly observing new test cases on storage. This parameter controls the rate of computing the remaining statistics.
## <a id="ControllerCommonParameters"></a>Section: `Parameters Common to All Controller Modules`
606
-
Parameters that are common to all Controller Modules (these parameters are supported by the base ControllerModule class). Each of these parameters is only relevant for distributed fuzzing, and will have no effect on standalone execution.
679
+
680
+
Parameters that are common to all core Controller Modules (these parameters are supported by the base ControllerModulePattern class). Note that some are relevant ONLY for distributed fuzzing and will have no effect on standalone execution.
681
+
682
+
### `controller.keepAllSeeds`
683
+
684
+
Value type: `<bool>`
685
+
686
+
Status: Optional
687
+
688
+
Default value: true
689
+
690
+
Usage: If set to true, all seed testcases will be saved and inserted into the fuzzing queue regardless of their coverage or quality. If set to false, only testcases that the feedback module decides to keep (eg have new coverage) will be kept. When set to true, more care should be given to seed redundancy and quality.
607
691
608
692
### `controller.corpusInitialUpdateMins`
609
693
610
694
Value type: `<int>`
611
695
612
-
Status: Optional
696
+
Status: Optional - Distributed fuzzing only
613
697
614
698
Default value: 5
615
699
616
700
Usage: This sets the minimum number of minutes that must pass before the controller will perform the first corpus update. Do not configure this parameter to be smaller than 5min unless you are using a very small number of VMFs.
617
701
702
+
### `controller.batchSize`
703
+
704
+
Value type: `<int>`
705
+
706
+
Status: Optional - Distributed fuzzing only
707
+
708
+
Default value: 1000
709
+
710
+
Usage: This sets a maximum number of new test cases that will be pulled in from the server at once. All the test cases will eventually be pulled in, but this parameter limits how many get pulled in at once (in order to limit the RAM usage by VMF). When this value is too large, VMF will use an excessive amount of RAM (with resulting slow downs, consequently this value may need to be set to be smaller if the test cases are large).
711
+
618
712
### `controller.corpusUpdateRateMins`
619
713
620
714
Value type: `<int>`
621
715
622
-
Status: Optional
716
+
Status: Optional - Distributed fuzzing only
623
717
624
718
Default value: 5
625
719
@@ -629,12 +723,15 @@ Usage: This sets a minimum rate for the controller to retrieve subsequent corpus
629
723
630
724
Value type: `<list of strings>`
631
725
632
-
Status: Optional
726
+
Status: Optional - Distributed fuzzing only
633
727
634
728
Default value: ["RAN_SUCCESSFULLY"]
635
729
636
730
Usage: This parameter controls which test case tags are retrieved by the controller. The default value is ["RAN_SUCCESSFULLY"], which will retrieve only the test cases ran succesfully (i.e. didn't hang or crash). This is the correct value if you are using VMF Core Modules in your fuzzer.
0 commit comments