The LLVM Sanitizers stage accomplished
<p>
I've managed to get the Memory Sanitizer to work for the elementary base system utilities, like ps(1), awk(1) and ksh(1).
This means that the toolchain is ready for tests and improvements.
I've iterated over the basesystem utilities and I looked for bugs, both in programs and in sanitizers.
The number of detected bugs in the userland programs was low, there merely was one reading of an uninitialized variable in ps(1).
<p>
<h1>A prebuilt LLVM toolchain</h1>
<p>
I've prepared a prebuilt toolchain with Clang, LLVM, LLDB and compiler-rt for NetBSD/amd64.
I prepared the toolchain on 8.99.12, however I have received reports that it works on other older releases.
<p>
Link: <a href="http://cdn.netbsd.org/pub/NetBSD/misc/kamil/llvm-clang-compilerrt-lldb-7.0.0beta_2018-01-24.tar.bz2">
llvm-clang-compilerrt-lldb-7.0.0beta_2018-01-24.tar.bz2</a>
<p>
The archive has to be untarballed to /usr/local (however it might work to some extent in other paths).
<p>
This toolchain contains a prebuilt tree of the LLVM projects from a snapshot of 7.0.0(svn).
It is a pristine snapshot of HEAD with patches from pkgsrc-wip for llvm, clang, compiler-rt and lldb.
<p>
<h1>Sanitizers</h1>
<p>
Notable changes in sanitizers, all of them are in the context of NetBSD support.
<p>
<ul>
<li>Added fstat(2) MSan interceptor.</li>
<li>Support for kvm(3) interceptors in the common sanitizer code.</li>
<li>Added devname(3) and devname_r(3) interceptors to the common sanitizer code.</li>
<li>Added sysctl(3) familty of functions interceptors in the common sanitizer code.</li>
<li>Added strlcpy(3)/strlcat(3) interceptors in the common sanitizer code.</li>
<li>Added getgrouplist(3)/getgroupmembership(3) interceptors in the common sanitizer code.</li>
<li>Correct ctype(3) interceptors in a code using Native Language Support.</li>
<li>Correct tzset(3) interceptor in MSan.</li>
<li>Correct localtime(3) interceptor in the common sanitizer code.</li>
<li>Added paccept(2) interceptor to the common sanitizer code.</li>
<li>Added access(2) and faccessat(2) interceptors to the common sanitizer code.</li>
<li>Added acct(2) interceptor to the common sanitizer code.</li>
<li>Added accept4(2) interceptor to the common sanitizer code.</li>
<li>Added fgetln(3) interceptor to the common sanitizer code.</li>
<li>Added interceptors for the pwcache(3)-style functions in the common sanitizer code.</li>
<li>Added interceptors for the getprotoent(3)-style functions in the common sanitizer code.</li>
<li>Added interceptors for the getnetent(3)-style functions in the common sanitizer code.</li>
<li>Added interceptors for the fts(3)-style functions in the common sanitizer code.</li>
<li>Added lstat(3) interceptor in MSan.</li>
<li>Added strftime(3) interceptor in the common sanitizer code.</li>
<li>Added strmode(3) interceptor in the common sanitizer code.</li>
<li>Added interceptors for the regex(3)-style functions in the common sanitizer code.</li>
<li>Disabled unwanted interceptor __sigsetjmp in TSan.</li>
</ul>
<p>
<h1>Base system changes</h1>
<p>
I've tidied up inclusion of the internal namespace.h header in libc.
This has hidden the usage of public global symbol names of:
<p>
<ul>
<li>strlcat -> _strlcat</li>
<li>sysconf -> __sysconf</li>
<li>closedir -> _closedir</li>
<li>fparseln -> _fparseln</li>
<li>kill -> _kill</li>
<li>mkstemp -> _mkstemp</li>
<li>reallocarr -> _reallocarr</li>
<li>strcasecmp -> _strcasecmp</li>
<li>strncasecmp -> _strncasecmp</li>
<li>strptime -> _strptime</li>
<li>strtok_r -> _strtok_r</li>
<li>sysctl -> _sysctl</li>
<li>dlopen -> __dlopen</li>
<li>dlclose -> __dlclose</li>
<li>dlsym -> __dlsym</li>
<li>strlcpy -> _strlcpy</li>
<li>fdopen -> _fdopen</li>
<li>mmap -> _mmap</li>
<li>strdup -> _strdup</li>
</ul>
<p>
I've also reverted the vadvise(2) syscall removal, from the previous month. This caused a regression in legacy code
recompiled against still supported compat layers. Newly compiled code will use a libc's stub of vadvise(2).
<p>
The purpose of these changes was to stop triggering interceptors recursively.
Such interceptors lead to sanitization of internals of unprepared (not recompiled with sanitizers) prebuilt code.
It's not trivial to sanitize libc's internals and the sanitizers are not designed to do so.
This means that they are not a full replacement of Valgrind-like software, but a a supplement in the developer toolbox.
Valgrind translates native code to a bytecode virtual machine, while sanitizers are designed to work with interceptors
inside the pristine libraries and embed functionality into the executable's code.
<p>
<h1>Future directions and goals</h1>
<p>
Possible paths in random order:
<ol>
<li>
In the quartet of UBSan (Undefined Behavior Sanitizer), ASan (Address Sanitizer), TSan (Thread Sanitizer), MSan (Memory Sanitizer)
we need to add the fifth basic sanitizer: LSan (Leak Sanitizer). The Leak Sanitizer (detector of memory leaks) demands
a stable ptrace(2) interface for processes with multiple threads (unless we want to build a custom kernel interface).
</li>
<li>
Integrate the sanitizers with the userland framework in order to ship with the native toolchain to users.
</li>
<li>
Port sanitizers from LLVM to GCC.
</li>
<li>
Allow to sanitize programs linked against userland libraries other than libc, librt, libm and libpthread;
by a global option (like MKSANITIZER) producing a userland that is partially prebuilt with a desired sanitizer.
This is required to run e.g. MSanitized programs against editline(3).
So far, there is no Operating System distribution in existence with a native integration with sanitizers.
There are 3rd party scripts for certain scripts to build a stack of software dependencies in order to validate.
</li>
<li>
Execute ATF tests with the userland rebuilt with supported flavors of sanitizers and catch regressions.
</li>
<li>
Finish porting of modern linkers designed for large C++ software, such as GNU GOLD and LLVM LLD.
Today the bottleneck with building the LLVM toolchain is a suboptimal linker GNU ld(1).
</li>
</ol>
<p>
I've decided to not open new battlefields and return now to porting LLDB and fixing ptrace(2).
<p>
<h1>Plan for the next milestone</h1>
<p>
Keep upstreaming a pile of local compiler-rt patches.
<p>
Restore the LLDB support for traced programs with a single thread.
<p>
<h2>This work was sponsored by The NetBSD Foundation.</h2>
<p>
The NetBSD Foundation is a non-profit organization and welcomes any donations to help us continue funding projects and services to the open-source community. Please consider visiting the following URL, and chip in what you can:
<p>
<a href="http://netbsd.org/donations/#how-to-donate">http://netbsd.org/donations/#how-to-donate</a>