Skip to content

Use shmem for forkserver several pointers #3249

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

Merged
merged 12 commits into from
May 19, 2025

Conversation

Evian-Zhang
Copy link
Contributor

Description

This will supersede #3229

Checklist

  • I have run ./scripts/precommit.sh and addressed all comments

@Evian-Zhang Evian-Zhang mentioned this pull request May 18, 2025
1 task
@wtdcode
Copy link
Member

wtdcode commented May 18, 2025

Consider merging your branch with #3233 as well? So that we can confirm the issue is fixed.

@Evian-Zhang
Copy link
Contributor Author

@wtdcode Sure. Merged.

@Evian-Zhang
Copy link
Contributor Author

Hmmmm, I don't think the failed CI is related to my change. Anyway, the android CI has successfully passed

@wtdcode
Copy link
Member

wtdcode commented May 18, 2025

It is #3248

@wtdcode
Copy link
Member

wtdcode commented May 18, 2025

Done, you could update your branch =).

use libafl_targets::{
map_input_shared_memory, map_shared_memory, start_forkserver, MaybePersistentForkserverParent,
};

#[no_mangle]
pub extern "C" fn libafl_start_forkserver() {
let Ok(mut shm_provider) = StdShMemProvider::new() else {
Copy link
Member

Choose a reason for hiding this comment

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

On Android StdShMemProvider spawns a server, we need to double check if this works for this use case (otherwise we should set a different provider here)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I totally agree. But I know little about Android, and I also don't know why the standard shmem provider needs a service wrapper. Maybe this should be checked by someone knowing this detail.

Copy link
Collaborator

Choose a reason for hiding this comment

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

We need a service on android to hand out ashmem handles via unix sockets, as that is the only way to get a 'reference' to an existing shared memory allocation.

Copy link
Member

Choose a reason for hiding this comment

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

This is for multi process IPC. For a forkserver we don't need that since the child can just inherit the allocations on fork

Copy link
Collaborator

Choose a reason for hiding this comment

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

True.

Copy link
Member

Choose a reason for hiding this comment

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

@Evian-Zhang probably we want to hard-code AshMemProvider here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmmm, is it possible for someone to setup a android fuzzer test CI so that we can test the correctness? I personally don't know any of android things, so although I'm willing to hard code it, I'm afraid we cannot ensure its correctness.

Copy link
Member

Choose a reason for hiding this comment

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

I will do that shortly these days. Will ping you if there is some failures.

Considering the slow performance of QEMU emulation, maybe we can just test simple fuzzers.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you! I will improve this shmem after your work :)

/// this shared memory.
///
/// Note that calling this method will result in a memory leak.
fn into_raw<T: Sized>(self) -> *mut T {
Copy link
Member

Choose a reason for hiding this comment

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

I don't 100% get the need for this function, why can't we keep a reference to the shmem around in general?

Copy link
Member

Choose a reason for hiding this comment

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

The shms are globally owned and we will need lots of global OnceCell to keep them. Note we can’t change EDGES_MAP or so to OnceCell because of symbol names. Therefore, I guess the intention is to avoid such duplicate cells? I’m okay with either way.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, just as @wtdcode said, the whole forksever logic relies on those global raw pointers, if we maintain those raw pointers and the shmem at the same time, we are creating potentially two mutable references to the same memory, which I think the memory leak is a better choice. And the original version of forksever also leaks the memory.

Copy link
Member

@domenukk domenukk May 19, 2025

Choose a reason for hiding this comment

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

Let's keep this as a (non-public) function inside the forkserver then, it shouldn't be something most people/not part of the ShMem trait, IMHO.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK.

@domenukk
Copy link
Member

Nice! Left some comments

env:
ANDROID_NDK_HOME: ${{ steps.setup-ndk.outputs.ndk-path }}
ANDROID_NDK_ROOT: ${{ steps.setup-ndk.outputs.ndk-path }}
run: cargo ndk -t x86_64 build
Copy link
Member

Choose a reason for hiding this comment

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

Can you add this to a justfile? We want to have every CI task in a justfile in the future

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry I don't really know about the detail. @wtdcode Can you do this in your branch? I could merge such changes.

Copy link
Member

Choose a reason for hiding this comment

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

@domenukk It is not a new fuzzer or test but just doing cross-building. I don't see a directory to place such justfiles. ./just seems common library scripts.

Copy link
Member

Choose a reason for hiding this comment

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

Create a repo-wide justfile, we'll need it at some point anyway #3099

Copy link
Member

Choose a reason for hiding this comment

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

But yes can be done later

@domenukk domenukk merged commit 0015254 into AFLplusplus:main May 19, 2025
111 checks passed
@domenukk domenukk mentioned this pull request May 19, 2025
1 task
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.

5 participants