--- wikisrc/users/maya.mdwn	2017/02/16 00:01:14	1.1
+++ wikisrc/users/maya.mdwn	2018/02/25 11:30:25	1.8
@@ -2,30 +2,29 @@
 
 ## Address Sanitizer (+UBsan) (preliminary) ##
 
-ASan reports memory violations, and detects many off-by-ones. It seems
-to produce very high quality reports.
+ASan reports memory violations, and detects many off-by-ones. It seems to produce very high quality reports.
 
-It only needs to be compiled on the resulting binary[1]. It cannot compile
-static objects so requires some fiddling with makefiles to disable those.
+It only needs to be compiled on the resulting binary[1]. It cannot compile static objects so requires some fiddling with makefiles to disable those.
 
 I've been running it on netbsd tests in the following manner[2]:
 
     cd /usr/src/tests/lib/libc
     env USETOOLS=never MK_SSP=no HAVE_SSP=no CFLAGS="-fno-omit-frame-pointer -O0 -g -ggdb -U_FORTIFY_SOURCE -fsanitize=address -fsanitize=undefined" LDFLAGS="-lasan -lubsan" make -j20
 
-    env ASAN_OPTIONS=alloc_dealloc_mismatch=0 LD_PRELOAD="/usr/lib/libasan.so /usr/lib/libubsan.so" atf-run
+    env ASAN_OPTIONS=alloc_dealloc_mismatch=0 LD_PRELOAD="/usr/lib/libasan.so /usr/lib/libubsan.so" atf-run # [3]
+
+    sysctl -w security.pax.aslr.enabled=0 # [4]
 
 1. Seems like this is a cause of worse reports, as in-library functions
 are not intercepted.
 
 2. Not even close to canonical commands, should probably be improved.
 
-3. ASAN_OPTIONS=alloc_dealloc_mismatch=0 is because atf-run itself
-    triggers a bug. Should have a look at it so this option doesn't
-    need to be disabled.
+3. To workaround "Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly". An alternative is to LD_PRELOAD and LD_LIBRARY_PATH an entirely separate libc, ld.elf_so, etc.
+
+4. ASan can be wrong about which function is faulting, if we're talking about functions internal to the library. Running it on a separate file or in GDB can be helpful. Worth trying if the failure doesn't make sense.
 
-Important note: ASan should not be run on production systems. [It can pose a
-security risk](http://www.openwall.com/lists/oss-security/2016/02/17/9).
+**Important note: ASan should not be run on production systems. [It can pose a security risk](http://www.openwall.com/lists/oss-security/2016/02/17/9).**
 
 ## Coverity ##
 
@@ -46,15 +45,12 @@ reported:
 - Setuid programs
 - Anything kernel
 - Stuff that runs as root
-
 - Library or other code you know well already
 - Drivers for hardware you actually own and can test
 
-Future ideas:
+## Future ideas: ##
 
-- GCC could be told to add ASan flags for all shared objects, making
-  it easier to build world with those flags
+- GCC could be told to add ASan flags for all shared objects, making it easier to build world with those flags
 - We could run all of NetBSD with ASan for some real world tests.
-- ASan for kernel? (subr_kmem.c has some flags which do some of the
-  work, could it do more?)
+- ASan for kernel? (subr_kmem.c has some flags which do some of the work, could it do more?)
 - Fuzzers are cool.