Change Details

As with MK_ASAN and MK_UBSAN, this lets one build parts of the tree, or the whole tree, with LLVM's Memory Sanitizer enabled. This enables runtime detection of uses of uninitialized memory. MSAN has some extra constraints relative to ASAN and UBSAN: - All code loaded into a process must be instrumented, otherwise false positives can arise easily. - An MSAN-instrumented DSO cannot be linked into an uninstrumented executable. - MSAN-instrumented executables must be position-independent. In particular, anything compiled with MK_PIE=no cannot be instrumented. In principle, libc.so does not need to be instrumented because the MSAN runtime provides interceptors which handle shadow map updates for various commit libc functions. However: - Some commonly used libc symbols are not intercepted currently (e.g., getc() and cgetent(), the latter is used by most ncurses applications). - There is at least one case where libc itself will generate a false positive: fts_sort() allocates memory using realloc(), which is intercepted, initializes the array inline, then sorts it with qsort(), which is also intercepted. MSAN ends up reporting that the memory is uninitialized. I think the proper solution for FreeBSD is to provide syscall interceptors in libsys, and nothing else. This would allow everything to be instrumented and would simplify maintenance. To give another example, libc internally uses _fstat() rather than fstat(), so interceptors won't catch it. We can fix that by adding another interceptor, but it makes much more sense to do so in libc/libsys rather than LLVM. This will also ease maintenance as new system calls are added. This commits introduces the glue needed to compile most of the base system with MSAN enabled. Currently I'm testing with the following flags: WITHOUT_KERBEROS= WITHOUT_LIB32= WITHOUT_BOOT= on amd64 and arm64. Sponsored by: Klara, Inc.

As with MK_ASAN and MK_UBSAN, this lets one build parts of the tree, or the whole tree, with LLVM's Memory Sanitizer enabled. This enables runtime detection of uses of uninitialized memory. MSAN has some extra constraints relative to ASAN and UBSAN: - All code loaded into a process must be instrumented, otherwise false positives can arise easily. - An MSAN-instrumented DSO cannot be linked into an uninstrumented executable. - MSAN-instrumented executables must be position-independent. In particular, anything compiled with MK_PIE=no cannot be instrumented. In principle, libc.so does not need to be instrumented because the MSAN runtime provides interceptors which handle shadow map updates for various commit libc functions. However: - Some commonly used libc symbols are not intercepted currently (e.g., getc() and cgetent(), the latter is used by most ncurses applications). - There is at least one case where libc itself will generate a false positive: fts_sort() allocates memory using realloc(), which is intercepted, initializes the array inline, then sorts it with qsort(), which is also intercepted. MSAN ends up reporting that the memory is uninitialized. I think the proper solution for FreeBSD is to provide syscall interceptors in libsys, and nothing else. This would allow everything to be instrumented and would simplify maintenance. To give another example, libc internally uses _fstat() rather than fstat(), so interceptors won't catch it. We can fix that by adding another interceptor, but it makes much more sense to do so in libc/libsys rather than LLVM. This will also ease maintenance as new system calls are added. This commits introduces the glue needed to compile most of the base system with MSAN enabled. Because of the aforementioned considerations, most applications will raise false positives currently, but this at least provides a mechanism to compile specific executables or libraries with MSan enabled. Currently I'm testing with the following flags: WITHOUT_KERBEROS= WITHOUT_LIB32= WITHOUT_BOOT= on amd64 and arm64. Sponsored by: Klara, Inc.

As with MK_ASAN and MK_UBSAN, this lets one build parts of the tree, or the whole tree, with LLVM's Memory Sanitizer enabled. This enables runtime detection of uses of uninitialized memory. MSAN has some extra constraints relative to ASAN and UBSAN: - All code loaded into a process must be instrumented, otherwise false positives can arise easily. - An MSAN-instrumented DSO cannot be linked into an uninstrumented executable. - MSAN-instrumented executables must be position-independent. In particular, anything compiled with MK_PIE=no cannot be instrumented. In principle, libc.so does not need to be instrumented because the MSAN runtime provides interceptors which handle shadow map updates for various commit libc functions. However: - Some commonly used libc symbols are not intercepted currently (e.g., getc() and cgetent(), the latter is used by most ncurses applications). - There is at least one case where libc itself will generate a false positive: fts_sort() allocates memory using realloc(), which is intercepted, initializes the array inline, then sorts it with qsort(), which is also intercepted. MSAN ends up reporting that the memory is uninitialized. I think the proper solution for FreeBSD is to provide syscall interceptors in libsys, and nothing else. This would allow everything to be instrumented and would simplify maintenance. To give another example, libc internally uses _fstat() rather than fstat(), so interceptors won't catch it. We can fix that by adding another interceptor, but it makes much more sense to do so in libc/libsys rather than LLVM. This will also ease maintenance as new system calls are added. This commits introduces the glue needed to compile most of the base system with MSAN enabled. Currently I'm testing with the followingBecause of the aforementioned considerations, flags: most applications will raise false positives currently, but this at least provides a mechanism to compile specific executables or libraries with MSan enabled. Currently I'm testing with the following flags: WITHOUT_KERBEROS= WITHOUT_LIB32= WITHOUT_BOOT= on amd64 and arm64. Sponsored by: Klara, Inc.