Afl.rs: Fuzzing Rust code with american-fuzzy-lop

It does exist - I implemented it several months ago and demoed it for a local meetup for fun:

https://github.com/thoughtpolice/afl/commit/e54c0237e934d734...

There was seemingly no interest at all in upstreaming this when I asked the afl-dev mailing list. My hope was that along with afl-clang-fast it could, in time, completely subsume the hacky `afl-gcc` and `afl-clang` scripts, making afl much faster, more robust and more portable out of the box (I initially tested on POWER8 machines). This component is under GPLv3, so it might possibly be due to licensing concerns. My other changes were accepted upstream (posted at a similar time), so that's just a speculative guess.

People are seemingly interested in this and I've seen this question pop up a few times since authoring the code originally. Perhaps it is worth maintaining a fork or patchset for wider availability... The above code works, but is less efficient than `afl-clang-fast` and strictly proof of concept. Neither of those are insurmountable. In fact because this code works on GIMPLE very directly, I see no reason why it couldn't work for things like gccgo or gcj, or even GNU Ada or FORTRAN, I suppose, with some tweaks.

Interestingly, a team at Oracle seems to have (at a similar, or later time) reinvented this same thing when they attempted to fuzz the Linux kernel with afl. But that source code doesn't exist publicly, it seems. Mine may not have even been suitable for them, even if they knew of it beforehand.

Because a lot of companies, at least those that develop their own internal software (on Linux for example) often stick to the compiler the system ships with, e.g. CentOS, say.

GCC is in that respect "enterprise ready" because it very likely was installed on the system already. And probably not the latest version either.

I'm not joking. Did you miss the part where I said the situation is worse for gcc? I do understand that this is a problem. I also do understand that it is not specific to Rust. Besides, convincing IT to allow rustup with an access-controlled toolchain directory shouldn't be a big deal in many cases. If they allowed one compiler, why not two? (Rustup can also be installed without sudo/admin, but I assume you are talking about situations where they want to restrict the executables running, not just globally installed executables). Yes, I know that in some cases they may not want two, but again, in those cases the GCC solution won't work either.

Note that tools like nvm etc are also quite necessary in their respective spheres for serious development. I was once in a situation where I couldn't even install node at a modern version without nvm.

For clippy, we are working on it, yes. For afl a simple fix exists (write the analog of -Xclang) but that fix will only work nicely if we ship llvm headers too which clang does (which we can, but it is a decision that can't be taken lightly). So no, we are not working on it. It is an interesting idea, and I will ping the relevant people (there are plans to ship "optional components" that you can obtain with rustup or download directly), but there are no concrete plans.

The general evolution of Rust is towards everything being done through rustup. If you want to install a cross compile toolchain, clippy, get stdlib sources, or a different compiler version, use rustup. All the solutions to the nightly problem involve rustup. I.e. instead of installing nightly and using clippy, you just `rustup install clippy` or something and the relevant clippy binary (or compatible source?) will be downloaded, one which will work even if you are on stable. Basically, rustup will be the thing you install when you want to use rust.

This is good, but as far as enterprise is concerned, you are still installing rustup, not rust. I'm not really sure what's wrong with this, but I'm sure some enterprise shops will have issues with this. For those which don't; the solution of having nightly installed via rustup in a frozen directory is not that much different, just unweildy.

I have worked in places where the computer is locked down for many teams. But not in a place where it would be locked down in a way that rustc would be okay but rustup would not. I'd love to hear more about such cases and discuss how it can be addressed, but I'd prefer email (username@gmail or @mozilla.com). Thanks :)

Please release this as a separate library like afl-rs so that we can use it :)

I am sure many people want this to exist. Tons of codebases are gcc-only and having proper GCC fuzzing is important.

This is not about a tool to provides a syntax, or makes commits. It's a tool that runs an instrumented version, only on the location the dev specifies, and reports actual bugs. If your team has a difference of opinion on whether you should fix actual bugs, you have larger problems.

That said, if your program only feasibly runs in a shared QA/dev environment, then yes, it can be understandable to prevent devs installing random tools and utilities there. But in that case, the problem is not so much hedonistic developers, but a lack of separating portions of the code base into individually testable components. Again, you probably have larger problems than whether your devs can install their own tooling (because it's of limited use in a lot of cases anyway).

To be clear, there are good reasons for restricting certain classes of tooling. You don't want the absent minded dev installing some cloud based source code integration tool. Then again, the only way to really protect against this is to isolate the dev network, and not allow internet access. I imagine the loss in productivity is fairly great. I'm sure there's a happy (or not!) medium in there, individual to most companies.