如何让ASAN使用4.12.3 Linux内核？

我试图设置/修复在我的docker集装箱asan。 为此，我使用一个简单的示例程序 

int main() { return 16; }

并与之编译 

 clang++ -std=c++1z -O1 -fsanitize=address test.cpp

随着铛4.0.1（它使没有什么区别，我使用）。

这产生了4.12.3-1-ARCH内核版本的错误，而且我没有4.12.3-1-ARCH谷歌或asan FAQ的东西似乎改变了这一点。 

 $ ./a.out ==13178==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING. ==13178==ASan shadow was supposed to be located in the [0x00007fff7000-0x10007fff7fff] range. ==13178==Process memory map follows: 0x00eda9b0a000-0x00eda9c4e000 /tmp/a.out 0x00eda9e4e000-0x00eda9e4f000 /tmp/a.out 0x00eda9e4f000-0x00eda9e52000 /tmp/a.out 0x00eda9e52000-0x00edaab37000 0x7f4266de9000-0x7f426713b000 0x7f426713b000-0x7f42672d8000 /usr/lib/libc-2.25.so 0x7f42672d8000-0x7f42674d7000 /usr/lib/libc-2.25.so 0x7f42674d7000-0x7f42674db000 /usr/lib/libc-2.25.so 0x7f42674db000-0x7f42674dd000 /usr/lib/libc-2.25.so 0x7f42674dd000-0x7f42674e1000 0x7f42674e1000-0x7f42674f7000 /usr/lib/libgcc_s.so.1 0x7f42674f7000-0x7f42676f6000 /usr/lib/libgcc_s.so.1 0x7f42676f6000-0x7f42676f7000 /usr/lib/libgcc_s.so.1 0x7f42676f7000-0x7f42676f8000 /usr/lib/libgcc_s.so.1 0x7f42676f8000-0x7f42676fb000 /usr/lib/libdl-2.25.so 0x7f42676fb000-0x7f42678fa000 /usr/lib/libdl-2.25.so 0x7f42678fa000-0x7f42678fb000 /usr/lib/libdl-2.25.so 0x7f42678fb000-0x7f42678fc000 /usr/lib/libdl-2.25.so 0x7f42678fc000-0x7f4267903000 /usr/lib/librt-2.25.so 0x7f4267903000-0x7f4267b02000 /usr/lib/librt-2.25.so 0x7f4267b02000-0x7f4267b03000 /usr/lib/librt-2.25.so 0x7f4267b03000-0x7f4267b04000 /usr/lib/librt-2.25.so 0x7f4267b04000-0x7f4267b1d000 /usr/lib/libpthread-2.25.so 0x7f4267b1d000-0x7f4267d1c000 /usr/lib/libpthread-2.25.so 0x7f4267d1c000-0x7f4267d1d000 /usr/lib/libpthread-2.25.so 0x7f4267d1d000-0x7f4267d1e000 /usr/lib/libpthread-2.25.so 0x7f4267d1e000-0x7f4267d22000 0x7f4267d22000-0x7f4267e33000 /usr/lib/libm-2.25.so 0x7f4267e33000-0x7f4268032000 /usr/lib/libm-2.25.so 0x7f4268032000-0x7f4268033000 /usr/lib/libm-2.25.so 0x7f4268033000-0x7f4268034000 /usr/lib/libm-2.25.so 0x7f4268034000-0x7f42681ae000 /usr/lib/libstdc++.so.6.0.24 0x7f42681ae000-0x7f42683ad000 /usr/lib/libstdc++.so.6.0.24 0x7f42683ad000-0x7f42683b7000 /usr/lib/libstdc++.so.6.0.24 0x7f42683b7000-0x7f42683b9000 /usr/lib/libstdc++.so.6.0.24 0x7f42683b9000-0x7f42683bc000 0x7f42683bc000-0x7f42683df000 /usr/lib/ld-2.25.so 0x7f42685b7000-0x7f42685c9000 0x7f42685cb000-0x7f42685da000 0x7f42685da000-0x7f42685df000 0x7f42685df000-0x7f42685e0000 /usr/lib/ld-2.25.so 0x7f42685e0000-0x7f42685e1000 /usr/lib/ld-2.25.so 0x7f42685e1000-0x7f42685e2000 0x7ffda4652000-0x7ffda4673000 [stack] 0x7ffda46cc000-0x7ffda46cf000 [vvar] 0x7ffda46cf000-0x7ffda46d1000 [vdso] 0xffffffffff600000-0xffffffffff601000 [vsyscall] ==13178==End of process memory map.

这很可能是由内核中最近发生的变化引起的，它改变了它加载PIE可执行文件的方式。 这个问题正在上游讨论 。

目前唯一的解决方法（除了使用旧的内核）是重新编译一个

  • CFLAGS += -no-pie
  • CFLAGS += -mllvm -asan-force-dynamic-shadow=1 （仅限Clang）

这至less从内核版本4.12.10-1-ARCH 。

另外（显然）更新的编译器版本的工作，但我没有亲自testing。

Interesting Posts