Thanks, @vanhauser-thc. I'm going to have to read that paper.

Is there a simple test that could be added to verify that the new functions a macros work as intended?

as long as the afl++ state in afl.rs does not include the feature this could not work :)
I first want to evaluate if this is something you would merge.

I first want to evaluate if this is something you would merge.

I will want to read the paper to convince myself this is worthwhile, and there should be a test to verify that this works correctly.

But, beyond that, I can't see any reason to object.

I added an example (wont work yet), but shows an easy example: finding a way through a maze to an exit.
Any fuzzer will be unable to solve this. With ijon it takes ~30 seconds.

cd afl
cargo afl build --example maze

finds the way through the maze in just 5-10 seconds:

We should wait with merging this until the AFL++ release (in about a week).

NOTE

1. I renamed libafl-llvm-rt to the correct name of afl-compiler-rt.o ... libafl makes it sound like the sister projects LibAFL.

2. Why are you using an archive file usually? In C/C++ projects that can result in issues with archive positions vs function resolution, which does not happen with object files. I doubt this is different for rust - so I am curious, why did you using that? I can put that back in, I removed that because it made my testing more difficult.

finds the way through the maze in just 5-10 seconds:

Nice!

2. Why are you using an archive file usually? In C/C++ projects that can result in issues with archive positions vs function resolution, which does not happen with object files.

I don't know the problem you are referring to. Could you provide me a link?

uh I somehow didn't push the change.

Let me paste it here:

diff --git a/cargo-afl/src/common.rs b/cargo-afl/src/common.rs
index 470f98c..df6eee2 100644
--- a/cargo-afl/src/common.rs
+++ b/cargo-afl/src/common.rs
@@ -52,12 +52,14 @@ pub fn afl_llvm_dir() -> Result<PathBuf> {
 }
 
 pub fn object_file_path() -> Result<PathBuf> {
-    afl_llvm_dir().map(|path| path.join("libafl-llvm-rt.o"))
+    afl_llvm_dir().map(|path| path.join("afl-compilter-rt.o"))
 }
 
+/* //Why is this needed?
 pub fn archive_file_path() -> Result<PathBuf> {
-    afl_llvm_dir().map(|path| path.join("libafl-llvm-rt.a"))
+    afl_llvm_dir().map(|path| path.join("afl-compiler-rt.a"))
 }
+*/
 
 pub fn plugins_available() -> Result<bool> {
     let afl_llvm_dir = afl_llvm_dir()?;
diff --git a/cargo-afl/src/config.rs b/cargo-afl/src/config.rs
index 7b849cd..3479a8e 100644
--- a/cargo-afl/src/config.rs
+++ b/cargo-afl/src/config.rs
@@ -38,7 +38,7 @@ pub struct Args {
 
 pub fn config(args: &Args) -> Result<()> {
     let archive_file_path = common::archive_file_path()?;
-    if !args.force && archive_file_path.exists() && args.plugins == common::plugins_available()? {
+    if !args.force && object_file_path.exists() && args.plugins == common::plugins_available()? {
         let version = common::afl_rustc_version()?;
         bail!(
             "AFL LLVM runtime was already built for Rust {version}; run `cargo afl config --build \
@@ -79,7 +79,7 @@ pub fn config(args: &Args) -> Result<()> {
     let work_dir = tempdir.path().join(AFL_SRC_PATH);
 
     build_afl(args, &work_dir)?;
-    build_afl_llvm_runtime(args, &work_dir)?;
+    //build_afl_llvm_runtime(args, &work_dir)?;
 
     if args.plugins {
         copy_afl_llvm_plugins(args, &work_dir)?;
@@ -129,6 +129,7 @@ fn build_afl(args: &Args, work_dir: &Path) -> Result<()> {
     Ok(())
 }
 
+/*
 fn build_afl_llvm_runtime(args: &Args, work_dir: &Path) -> Result<()> {
     let object_file_path = common::object_file_path()?;
     let _: u64 = std::fs::copy(work_dir.join("afl-compiler-rt.o"), &object_file_path)
@@ -151,6 +152,7 @@ fn build_afl_llvm_runtime(args: &Args, work_dir: &Path) -> Result<()> {
 
     Ok(())
 }
+*/
 
 fn copy_afl_llvm_plugins(_args: &Args, work_dir: &Path) -> Result<()> {
     // Iterate over the files in the directory.

added a test.

$ cargo test integration_maze

[...]

[*] Fuzzing test case #148 (162 total, 1 crashes saved, state: started :-), mode=explore, perf_score=800, weight=0, favorite=1, was_fuzzed=0, exec_us=28, hits=0, map=152, ascii=0, run_time=0:00:00:03)...


+++ Testing aborted programmatically +++
[*] Statistics: 161 new corpus items found, 0.60% coverage achieved, 1 crashes saved, 0 timeouts saved, total runtime 0 days, 0 hrs, 0 min, 3 sec
[+] We're done here. Have a nice day!

test integration_maze ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 2 filtered out; finished in 19.72s

there are built failures for arm64 I do not understand why they happen. does arm64 need something specific handling?

there are built failures for arm64 I do not understand why they happen. does arm64 need something specific handling?

Not that I know of, but that's also not a platform that we normally test. Could you point me to the failures?

Ah it looks like the CI failures happen when the "have afl++ native plugins" is false - obviously, as ijon requires that, and hence the maze cannot be solved.
I do not know the code base well enough to be able to put the right check into cargo-afl/tests/integration.rs:integration_maze() to only be run when the native plugins are present. could you add this please?

could you add this please?

There may be a better way, but 19d50be should work.

I will update the PR once the release commit is done, then it can be merged.

two items:

1. linter issue:

error: use of `writeln!(stderr(), ...).unwrap()`
  --> cargo-afl/tests/integration.rs:65:9
   |
65 | /         writeln!(
66 | |             std::io::stderr(),
67 | |             "Skipping `integration_maze` test as plugins are unavailable"
68 | |         )
69 | |         .unwrap();
   | |_________________^ help: try: `eprintln!("Skipping `integration_maze` test as plugins are unavailable")`
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#explicit_write
   = note: `-D clippy::explicit-write` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(clippy::explicit_write)]`

as this is your code dunno how you want this fixed.

2. in C, IJON macros are all written in uppercase, e.g. IJON_MAX(foo); IJON_SET(bar);
   do you want this for rust as well? I kept them lowercase, as it seems this is more rust-y, but honestly I do not care either way :-)

I will update the PR once the release commit is done, then it can be merged.

two items:

1. linter issue: ... as this is your code dunno how you want this fixed.

I opened a Clippy issue to see whether they would consider disabling that lint in test code: rust-lang/rust-clippy#15780

But, for now, you can just precede the statement with:

#[allow(clippy::explicit_write)]

2. in C, IJON macros are all written in uppercase, e.g. IJON_MAX(foo); IJON_SET(bar);
   do you want this for rust as well? I kept them lowercase, as it seems this is more rust-y, but honestly I do not care either way :-)

Please keep it the Rusty way.

Just FYI, I still have to review the PR carefully. I may have additional suggestions.

One Ubuntu instance is failing, and I notice that it executed the maze twice. the first time it works fine, the second there is not a single coverage item found.
What is different between the two runs?

One Ubuntu instance is failing, and I notice that it executed the maze twice.

I'm having trouble spotting the successful run. Could you point me to where in GitHub's output this is indicated?

Can I take it the test passes consistently locally?

One Ubuntu instance is failing, and I notice that it executed the maze twice.

I'm having trouble spotting the successful run. Could you point me to where in GitHub's output this is indicated?

https://github.com/rust-fuzz/afl.rs/actions/runs/18123061265/job/51571862454?pr=655
Line 486 and before.
In Line 487 it starts another run on the maze that does not work at all.

I don't know what is different between the two runs.

Can I take it the test passes consistently locally?

works without issues for me. and for the CI, except for that one specific test target - see above

I think like 486 is a different test:

EDIT: But to your point, I do wonder if the tests could be interfering with each other somehow.

then I don't know why it is failing.

Rust / build (ubuntu-latest, nightly, true, clang) (pull_request) Failing after 8m
it succeeded yesterday, and the changes since then have nothing to do with plugins, so I think this is a breaking change in ubuntu-latest.

all other ubuntu and macos variants are succeeding.

Is there any chance the feature is non-deterministic in AFL++?

Fuzzing should not be deterministic :-)

Issue was this:

[*] Fuzzing test case #0 (1 total, 0 crashes saved, state: started :-), mode=explore, perf_score=100, weight=1, favorite=1, was_fuzzed=1, exec_us=45, hits=0, map=8, ascii=0, run_time=0:00:00:10)...

it did not find a single bit of coverage, and that means something went very wrong. and this is not something that happens due bad RNG.

But now the CI is green. so dunno what happened. between the failed CI and the green CI there was only a clippy ignore change, so I can only attribute this to ubuntu-latest/llvm issues.

new AFL++ version was released, this could now be merged.
If you want changes, I am available the next 24 hours, then I will be AFK for some days.

You probably noticed this, but two ubuntu-latest jobs failed this time.

I would like the tests to pass consistently.

I can think of three possibilities right now:

• a problem with how afl.rs calls AFL++
• a problem with the testing infrastructure itself (e.g., fuzz_example)
• something else

I tried the newest AFL++ with ubuntu:latest with a Docker container and everything including ijon runs fine.
no clue what the issue could be. would need to debug in their container ...

no clue what the issue with the CI is.
cargo test integration_maze works fine for me

no clue what the issue with the CI is. cargo test integration_maze works fine for me

Sorry, but doescargo test integration_maze really pass 100% of the time for you? Because when I test it, it does occasionally fail.

Here, for example, is a run where it seems to get stuck at 116 corpus entries. It starts to find its way out, but the time remaining is not sufficient to find a crash: https://github.com/smoelius/afl.rs/actions/runs/18360989062/job/52304402582#step:9:597

Would you consider adapting integration_maze so that it tries three times (say), and so long as a crash is found one of those times, the test is considered a success?

no clue what the issue with the CI is. cargo test integration_maze works fine for me

Sorry, but doescargo test integration_maze really pass 100% of the time for you? Because when I test it, it does occasionally fail.

Here, for example, is a run where it seems to get stuck at 116 corpus entries. It starts to find its way out, but the time remaining is not sufficient to find a crash: https://github.com/smoelius/afl.rs/actions/runs/18360989062/job/52304402582#step:9:597

Would you consider adapting integration_maze so that it tries three times (say), and so long as a crash is found one of those times, the test is considered a success?

for me it works 100% of the time.
but the CI env on github uses cheap instances so yeah it could be tight. increased to 15 seconds and 3 attempts.

yay green!

done

Thanks, again. 🙏