search for: internal_mmap

...of llc. >Also, did you reply to my comments about reusing compiler-rt code from >sanitizer_common? >I see lots of places in lib/safestack where you duplicate existing >functionality from lib/sanitizer_common Yes, we would like to use some of the functions from sanitizer_common (e.g., internal_mmap/munmap and some pthread-related functions), but linking the entire sanitizer_common just for that might be an overkill. E.g., it can make small programs like coreutils up to 3x larger, and it requires compiling with -pthread. Perhaps we can move those functions to separate files in sanitizer_common...

First off, thanks -- this is a pretty great library and it feels like I'm learning a lot. I'm getting some more experience with libfuzzer and finding that I have a couple of questions: - How does libfuzzer decide to write a new test file? What distinguishes this one from all the other cases for which new test inputs were not written? Must be something about the path taken through the

...00000000579b97 in fuzzer::Fuzzer::StaticAlarmCallback () at /home/brian/tmp/testing/llvm_src//llvm/lib/Fuzzer/FuzzerLoop.cpp:57 #20 0x0000000000572355 in fuzzer::AlarmHandler () at /home/brian/tmp/testing/llvm_src//llvm/lib/Fuzzer/FuzzerUtil.cpp:49 #21 <signal handler called> #22 __sanitizer::internal_mmap (addr=0x621000f20000, length=65536, prot=prot at entry=3, flags=flags at entry=50, fd=fd at entry=-1, offset=offset at entry=0) #23 0x00000000004edbf8 in __sanitizer::MmapFixedOrDie (fixed_addr=fixed_addr at entry=107820874858496, size=size at entry=65536) #24 0x00000000004479b1 in MapWithCallback...

Dear LLVM developers, Our team has developed an LLVM-based protection mechanism that (i) prevents control-flow hijack attacks enabled by memory corruption errors and (ii) has very low performance overhead. We would like to contribute the implementation to LLVM. We presented this work at the OSDI 2014 conference, at several software companies, and several US universities. We received positive