TinyInst for Linux

[tokatoka]

they support linux now

[domenukk]

Do we even support MacOS? I thought it tinyinst libafl was Windows only?

[tokatoka]

tinyinst-bindings itself works we even have CI. for libafl-tinyinst i don't know

[am009]

I just started working on this.

At first, I used the UnixShMemProvider, but I found that it uses shmget/shmat, while the harness uses shm_open. So I switched to MmapShMemProvider.

    #[cfg(target_vendor = "apple")]
    let mut shmem_provider = UnixShMemProvider::new().unwrap();

    #[cfg(target_os = "linux")]
    let mut shmem_provider = MmapShMemProvider::new().unwrap();

However, the fuzzer tinyinst_simple's harness (fuzzers/tinyinst_simple/test/test.cpp) still fails at shm_open. After debugging, I found that the fd is used as the shared memory id, instead of the shared memory filename:

• First, the fuzzer calls shm_open("/libafl_1344706_2656399188", ...), and it returns a fd (for example, 3)
• Then, the ShMemId is set to the fd (after converting to string, "3"), and is passed as the harness's argument ("test.exe -m 3"). https://github.com/AFLplusplus/LibAFL/blob/93f67aa405092594a85c26ea1015944593127895/libafl_bolts/src/shmem.rs#L686-L692
• Then the harness maps the shared memory by calling shm_open("3", ...), and the call failed with "Error in shm_open: No such file or directory". It should pass the file name to shm_open (shm_open("/libafl_1344706_2656399188", ...))

On Windows, the Win32ShMemProvider sets the ShMemId to the shared memory filename (format!("libafl_{}", uuid.simple())).

Is this the expected behavior on MacOS? I don't have a MacOS device to test it. Or the child process inherits the file descriptor of the shared memory and it should skip the shm_open and just call the mmap?

By the way, I'm not sure but I feel like keeping the "test.exe" as the executable name even on Linux. First, it uses less conditional compilation#[cfg(target_os = "linux")]. And second, there is a folder called test that prevents me from creating a file with the same name.

[tokatoka]

Is this the expected behavior on MacOS?

No it is not supposed to work on MacOS

[am009]

MmapShMem has both fd and the path passed to shm_open, but there is a disagreement on which should be set as ShMem.id():

• When the MmapShMem is wrapped in ShMemService (especially on MacOS, StdShMemService is aliased to ShMemService<MmapShMemProvider>), the ShMemService sends the shmem fd using socket. So it assumes the id is fd number, and tries to parse the id to get the fd. This is also why some MacOS tests failed.
• When the MmapShMem is used directly (in this case), the path passed to shm_open is expected to be the id, so that the harness can use shm_open to get the memory.

In my opinion, ShMem.id() represents something that can be used to fetch the shared memory, so these two cases are both reasonable.

I think we can add another type (for example, NamedMmapShMem) that has identical behavior as MmapShMem, but its id is set to the shm_open path instead of the fd number. (also add its provider NamedMmapShMemProvider).

[am009]

I didn't realize that we could still use UnixShMemProvider and shmat instead of shm_open on Linux. I have updated the PR.