Implementation questions of AFL

365 views
Skip to first unread message

Hongxu Chen

unread,
May 16, 2018, 3:44:12 PM5/16/18
to afl-...@googlegroups.com
Dear Michal and AFL users,

    We are interested in AFL's implementations and have read the code recently. But we are confused with some details.

    - In AFL, the shared memory is attached with "shmget" rather than "mmap". It seems that mmap is more recommended while shmget is more widely supported. So why AFL chooses the former (AFL indeed also uses mmap for tracking mutated bytes but that's for another purpose)? And can we expect "mmap" to bring slowdown or boost performance compared to current implementation?
    - AFL handles "timeout" with a relatively complicated code flow, while there is an alternative by using "select" syscall -- the problem we can see is that from Linux's manual, SA_RESTART does not work with "select", therefore there may be some portability issues compared to current implementation. Are there other benefits?


Best Regards,
Hongxu

Jakub Wilk

unread,
May 17, 2018, 3:12:21 PM5/17/18
to afl-...@googlegroups.com
* Hongxu Chen <leftco...@gmail.com>, 2018-05-17, 03:43:
>- In AFL, the shared memory is attached with "shmget" rather than
>"mmap". It seems that mmap is more recommended while shmget is more
>widely supported. So why AFL chooses the former (AFL indeed also uses
>mmap for tracking mutated bytes but that's for another purpose)?

If you want to share memory across execve(), you need not only mmap(),
but also shm_open(), and the latter is just awful. For AFL purposes,
shmget()+shmat() is a much nicer API.

BTW, there's a comment in afl-as.h that seems to imply that the
instrumentation uses both shmget() and shmat(), whereas it uses only the
latter. Michal, you may want to fix that.

>And can we expect "mmap" to bring slowdown or boost performance
>compared to current implementation?

I wouldn't expect any noticeable difference.

>- AFL handles "timeout" with a relatively complicated code flow, while
>there is an alternative by using "select" syscall

One difficulty is that if there's no forkserver, afl-fuzz has to wait
for the child to terminate. This not supported directly by select().

>the problem we can see is that from Linux's manual, SA_RESTART does not
>work with "select", therefore there may be some portability issues
>compared to current implementation.

POSIX says: "If SA_RESTART has been set for the interrupting signal, it
is implementation‐defined whether the function restarts or returns with
EINTR."

All in all, I'm skeptical if using select() will actually make the code
simpler.

--
Jakub Wilk

Hongxu Chen

unread,
May 17, 2018, 3:42:27 PM5/17/18
to afl-...@googlegroups.com, jw...@jwilk.net
Thanks Jakub for your reply!
One of the reasons that I don't like "shmget" is that when allocating *multiple* bulks (for quite different purposes, and we don't think we appending a continuous bulk of share memory is elegant in this scenario) of shared memory (AFL fuzzer itself only uses one bulk with IPC_PRIVATE therefore there wont be any issues), and if the fuzzer fails to exit normally due to some reasons, the shared memory is still there unless manually detaching with "ipcrm", while a friend of mine tells me that "mmap"ed memory can be released by the kernel automatically (I'm not familiar with Linux programming and haven't tried it myself).
Do you have any suggestions?

Best Regards,
Hongxu



--
Jakub Wilk

--
You received this message because you are subscribed to the Google Groups "afl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to afl-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hongxu Chen

unread,
Sep 19, 2018, 2:55:51 AM9/19/18
to afl-...@googlegroups.com
Dear AFL user list,

    I noticed that in afl-llvm-rt.o.c there is *an extra* initialization for__afl_area_initial. If I understand correctly, the memory that __afl_area_ptr points to is the one allocated in the fuzzer process and attached in the target projects via __afl_map_shm.
    Then what's the purpose of this allocation?
    I saw some comments between the code segments:


    /* Globals needed by the injected instrumentation. The __afl_area_initial region
   is used for instrumentation output before __afl_map_shm() has a chance to run.
   It will end up as .comm, so it shouldn't be too wasteful. */
   u8  __afl_area_initial[MAP_SIZE];
   u8* __afl_area_ptr = __afl_area_initial;

And:

    /* If we're running under AFL, attach to the appropriate region, replacing the
     early-stage __afl_area_initial region that is needed to allow some really
     hacky .init code to work correctly in projects such as OpenSSL. */

But I cannot understand them. Can anyone please explain a bit?


Best Regards,
Hongxu

Reply all
Reply to author
Forward
0 new messages