Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix regex fixing generated bindings for QEMU #2163

Merged
merged 5 commits into from
May 13, 2024

Conversation

rmalmain
Copy link
Collaborator

@rmalmain rmalmain commented May 12, 2024

Fix #2128
Also, avoid writing 2 times bindings to filesystem.

* Do not write 2 times bindings to filesystem

* Update stub bindings
@@ -155,7 +155,7 @@ pub fn generate(
bindings
.allowlist_type("CPUX86State")
.allowlist_type("X86CPU")
} else if cpu_target == "arssssm" {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great typo

@@ -13703,7 +13702,7 @@ extern "C" {
extern "C" {
pub fn libafl_add_read_hook(
gen: ::std::option::Option<
unsafe extern "C" fn(
extern "C" fn(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be unsafe? The raw pointer will later be dereferenced (or is the later function marked unsafe?)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe, but then we need to keep the other similar function signatures consistent.
In any case, here it's a problem since we were transmuting a safe function pointer to an unsafe one, which is not a good idea IMHO.
I think the rationale behind making it safe is that we are using it through the Qemu struct, which is unsafe by nature. I'd say that as long as the signature of the function pointer is correct, it should not cause additional safety issues.

FYI it's used concretely there.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO a function that takes a *mut ptr and potentially dereferences that can never be safe. So I would argue the original function should already be unsafe (and then we don't transmute safe -> unsafe either)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At first glance, looks like libafl_gen_rw should be marked unsafe as well, then?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah lol nevermind it's C :P It's all unsafe anyway

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds reasonable, it's true safe rust allows the creation of any raw pointer. It's better to properly propagate the unsafeness even for an unsafe structure.

Copy link
Collaborator Author

@rmalmain rmalmain May 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other good point is that we can remove the ugly fix of the bindings.

@domenukk domenukk merged commit b0d9567 into main May 13, 2024
102 checks passed
@domenukk domenukk deleted the fix_minimal_docker_compilation branch May 13, 2024 15:41
riesentoaster pushed a commit to riesentoaster/LibAFL that referenced this pull request May 24, 2024
* Fix regex fixing generated bindings

* Do not write 2 times bindings to filesystem

* Update stub bindings

* fmt

* clippy

* fmt

* use `unsafe extern "C"` instead of `extern "C"`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

libafl_qemu fails to build in rust:1.77 Docker image
2 participants