> ASan already has the dynamic shadow as an option, and it's default > mode > on 64-bit windows, where the kernel is actively hostile to asan. > On Linux, we could enable it by > clang -fsanitize=address -O dummy.cc -mllvm -asan-force-dynamic- > shadow=1 > (not heavily tested though). > > The problem is that this comes at a cost that we are very reluctant to > pay. > Dynamic shadow means one extra load and one extra register stolen per > function, > which increases the CPU usage and code size. Can libraries compiled with dynamic be mixed with an executable or other shared objects without it? It could be the default with -fPIC / -fPIE without changing the default for position dependent executables. Code isn't really PIC if it can't be mapped within a large range. The performance hit would be paid by people using dynamic libraries + PIE by default, but not non-PIE executables and static libraries (unless they get compiled with -fPIC to allow linking in a dynamic library, which is uncommon). I'm sure a fix can be found either in the kernel or the sanitizers for this specific PIE base move, but the problem isn't limited to this. There are currently other issues. Try: sysctl vm.mmap_rnd_bits=32 sysctl vm.mmap_rnd_compat_bits=16 IIRC that breaks some sanitizers at least for 32-bit executables. Similar issues happen with certain arm64 address space configs since it offers a bunch of choices (3 vs. 4 level page tables, different page sizes). -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
