Tips for using analyzers on NetBSD

Address Sanitizer (+UBsan) (preliminary)

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.

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 # [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. 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.

Coverity

Coverity is a static analyzer.

You can see a part of its output in coverity-updates@, and a lot more if you go to the website (sign up with your netbsd email or poke someone for access).

A lot of the reports are about strncpy/strcpy or in code that belongs to GCC (in the case of userland), you can tackle this by limiting results to a particular directory (click the folder icon). You can also sort by issue.

Some suggestions for things to focus on, as there are many defects reported:

Future ideas: