Various fixes for CI (#423)

* Various fixes

* fix try_from for cores

* no_std

bindings/pylibafl/Cargo.toml

@@ -5,7 +5,7 @@ edition = "2021"
 
 [dependencies]
 pyo3 = { version = "0.15", features = ["extension-module"] }
-libafl_qemu = { path = "../../libafl_qemu", version = "0.7", features = ["python"] }
+libafl_qemu = { path = "../../libafl_qemu", version = "0.7", features = ["python"], features = ["x86_64"] }
 libafl_sugar = { path = "../../libafl_sugar", version = "0.7", features = ["python"] }
 
 [build-dependencies]

docs/src/message_passing/spawn_instances.md

@@ -4,7 +4,7 @@ Multiple fuzzer instances can be spawned using different ways.
 
 ## Manually, via a TCP port
 
-The straightforward way to do Multi-Threading is to use the `LlmpRestartingEventManager`, and specifically to use `setup_restarting_mgr_std`.
+The straightforward way to do Multi-Threading is to use the `LlmpRestartingEventManager`, specifically to use `setup_restarting_mgr_std`.
 It abstracts away all the pesky details about restarts on crash handling (for in-memory fuzzers) and multi-threading.
 With it, every instance you launch manually tries to connect to a TCP port on the local machine.
 
@@ -20,7 +20,7 @@ While it's called "restarting" manager, it uses `fork` on Unix operating systems
 ## Launcher
 
 The Launcher is the lazy way to do multiprocessing.
-You can use the Launcher builder to create a fuzzer that spawns multiple nodes, all using restaring event managers.
+You can use the Launcher builder to create a fuzzer that spawns multiple nodes, all using restarting event managers.
 An example may look like this:
 
 ```rust,ignore
@@ -40,7 +40,7 @@ An example may look like this:
 This first starts a broker, then spawns `n` clients, according to the value passed to `cores`.
 The value is a string indicating the cores to bind to, for example, `0,2,5` or `0-3`.
 For each client, `run_client` will be called.
-On Windows, the Launcher will restart each client, while on Unix it will use `fork`.
+On Windows, the Launcher will restart each client, while on Unix, it will use `fork`.
 
 ## Other ways
 

fuzzers/fuzzbench_qemu/Cargo.toml

@@ -13,6 +13,6 @@ debug = true
 
 [dependencies]
 libafl = { path = "../../libafl/" }
-libafl_qemu = { path = "../../libafl_qemu/" }
+libafl_qemu = { path = "../../libafl_qemu/", features = ["x86_64"] }
 clap = { version = "3.0.0-rc.4", features = ["default"] }
 nix = "0.23.0"

fuzzers/libfuzzer_stb_image_sugar/src/main.rs

@@ -18,13 +18,13 @@ pub fn main() {
     fuzz(
         &[PathBuf::from("./input")],
         PathBuf::from("./output"),
-        &[1],
+        &Cores::all(),
         1337,
     );
 }
 
 /// The actual fuzzer
-fn fuzz(input_dirs: &[PathBuf], output_dir: PathBuf, cores: &[usize], broker_port: u16) {
+fn fuzz(input_dirs: &[PathBuf], output_dir: PathBuf, cores: &Cores, broker_port: u16) {
     // Call LLVMFUzzerInitialize() if present.
     let args: Vec<String> = env::args().collect();
     if libfuzzer_initialize(&args) == -1 {

libafl/src/bolts/os/mod.rs

@@ -232,6 +232,14 @@ impl From<Vec<usize>> for Cores {
     }
 }
 
+#[cfg(feature = "std")]
+impl TryFrom<&str> for Cores {
+    type Error = Error;
+    fn try_from(cores: &str) -> Result<Self, Self::Error> {
+        Self::from_cmdline(cores)
+    }
+}
+
 /// Parses core binding args from user input
 /// Returns a Vec of CPU IDs.
 /// `./fuzzer --cores 1,2-4,6` -> clients run in cores 1,2,3,4,6

libafl_sugar/Cargo.toml

@@ -21,7 +21,7 @@ pyo3-build-config = { version = "0.14.5", optional = true }
 [dependencies]
 libafl = { path = "../libafl", version = "0.7.0" }
 libafl_targets = { path = "../libafl_targets", version = "0.7.0" }
-libafl_qemu = { path = "../libafl_qemu", version = "0.7.0" }
+libafl_qemu = { path = "../libafl_qemu", version = "0.7.0", features = ["x86_64"] }
 typed-builder = "0.9.0" # Implement the builder pattern at compiletime
 #pyo3 = { version = "0.15", features = ["extension-module"], optional = true }
 pyo3 = { version = "0.15", optional = true }