AFL++ support for native simulator platform

[jayashree505]

Adding support for AFL++ instrumentation in the native simulator platform. This change expects that the AFL++ compiler is installed and available in the system PATH.

More information on setting up AFL toolchain can be found here - https://aflplus.plus/building/

Build application using the following command:
west -v build -b native_sim/native/64 samples/hello_world -p -- -DZEPHYR_TOOLCHAIN_VARIANT=llvm -DCONFIG_ARCH_POSIX_AFLPLUSPLUS=y

[github-actions]

Hello @jayashree505, and thank you very much for your first pull request to the Zephyr project!
Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary.
If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jayashree505]

Hi, this PR is aligned with the following RFC - #103685

[aescolar]

This would not be the way to do it, but before going into why, let me ask a question:
After replacing the compiler, then what?: What will happen during execution? What will be fuzzed?

[tejlmand]

The AFL++ tool looks something a bit in between a SCA tool and the compiler.

Please take a look at the SCA tool integration https://docs.zephyrproject.org/latest/develop/sca/index.html
https://github.com/zephyrproject-rtos/zephyr/tree/main/cmake/sca

All the SCA tools today behaves slightly different, some running independent of the compiler, some apply flags to compiler invocation, some are used for launching the compiler.

I feel AFL++ will fit nicely with the SCA scheme, and my initial suggestion would be to take a look at the sparse or coverity implementation.

[tejlmand]

n is the default for Kconfigs and should only be used in cases where there exists a default y that should be overruled, for example in a defconfig file.

Suggested change

default n

[tejlmand]

Suggested change

	bool "Enable AFL++ support"
	bool "AFL++"

as per https://docs.zephyrproject.org/latest/build/kconfig/tips.html#prompt-strings

For a Kconfig symbol that enables a driver/subsystem FOO, consider having just “Foo” as the prompt, instead of “Enable Foo support” or the like.
It will usually be clear in the context of an option that can be toggled on/off, and makes things consistent.

[tejlmand]

we should not overwrite a given compiler this way behind the scenes of the user.

[jayashree505]

This would not be the way to do it, but before going into why, let me ask a question: After replacing the compiler, then what?: What will happen during execution? What will be fuzzed?

Yes, I guess that is part of the reason why I raised an RFC and not a PR initially. I am able to fuzz the instrumented zephyr.exe with afl-fuzz (the screen shot of which I posted in #103685).

I understand that AFL++ works on file input, which means for embedded applications, it can be hard to scale without modeling the peripherals. Therefore, this is only for the Posix platform for now (and it can possibly help test applications having file input in their Posix port). Further down, we may have a framework to create simple models of peripherals to provide input or/and also leverage the AFL QEMU mode that does binary only fuzzing.

I am still exploring the options! :) I would love to know your reasoning/comments on this integration. I am happy to contribute as per the community's suggestions. If there could be a discussion on this on any of the Zephyr Security regular meetups, that would be great too!

[jayashree505]

The AFL++ tool looks something a bit in between a SCA tool and the compiler.

Please take a look at the SCA tool integration https://docs.zephyrproject.org/latest/develop/sca/index.html https://github.com/zephyrproject-rtos/zephyr/tree/main/cmake/sca

All the SCA tools today behaves slightly different, some running independent of the compiler, some apply flags to compiler invocation, some are used for launching the compiler.

I feel AFL++ will fit nicely with the SCA scheme, and my initial suggestion would be to take a look at the sparse or coverity implementation.

Thank you for your suggestions and the review comments. I will look into these and keep the pointers in mind for future contributions.