qemu: Can we avoid setting features based on env variables?

[Marcondiro]

Hello,
In libafl_qemu, some feautures can be set from env variables by the build script:

LibAFL/libafl_qemu/build_linux.rs

Lines 24 to 30 in 1113879

	let emulation_mode = if cfg!(feature = "usermode") {
	"usermode".to_string()
	} else if cfg!(feature = "systemmode") {
	"systemmode".to_string()
	} else {
	env::var("EMULATION_MODE").unwrap_or_else(|_| "usermode".to_string())
	};

This approach prevents us from using optional dependencies bound to features since cargo resolves the dependencies before the build script sets these features.

What is the advantage of supporting the configuration through env vars instead of directly setting features?
Could this be removed or it is used somewhere?
Thanks

[domenukk]

From a rust perspective, it's the right thing to do it via feature flags. I wonder if anything down the road in C land depends on env variables?

[Marcondiro]

It looks like the env var is a fallback in case the feature is not set, so I think it's unlikely that anything down the road relies on it...
Maybe @andreafioraldi knows why they are there?

[andreafioraldi]

it is there to be able to build generic fuzzers that can be configured with env like aflqemu, but if you find a way to do it in the fuzzers not in the lib got for it Il mer 4 set 2024, 13:55 Marco C. ***@***.***> ha scritto:

…

It looks like the env var is a fallback in case the feature is not set, so I think it's unlikely that anything down the road relies on it... Maybe @andreafioraldi <https://github.com/andreafioraldi> knows why they are there? — Reply to this email directly, view it on GitHub <#2505 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD3LJ6VCHMB3J4EOWN3SEGTZU3YK7AVCNFSM6AAAAABNTWJIXGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANJUGQ2TENA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Marcondiro]

Ok thanks!
So for stuff that can be set through features, the corresponding env var could be dropped right?

[domenukk]

We probably still want a way for the user to chose these features at compile-time for the final libafl_qemu / qemuafl alternative. Maybe instead of env variables we can specify the features as feature flags? It should be somewhat usable without changing any toml files.