LLVM ships a hardened memory allocator called Scudo:
https://llvm.org/docs/ScudoHardenedAllocator.html. This allocator
provides additional mitigations against heap-based vulnerabilities, but
retains sufficient performance to be safely run in production
applications.
While ideal Swift applications are obviously written in pure Swift, in
practice most applications contain some amount of code written in
less-safe languages. Additionally, plenty of Swift programs themselves
contain unsafe code, particularly when attempting to implement
high-performance data structures. These sources of unsafety introduce
the risk of memory issues, and having the option to use the Scudo
allocator is a useful defense-in-depth tool.
This patch enables `-sanitize=scudo` as an extra `swiftc` flag. This
sanitizer is only supported on Linux, so no further work is required to
enable it on Windows or Apple platforms. As this "sanitizer" is only a
runtime component, we do not require any wider changes to instrument
code. This is similar to clang's `-fsanitize=scudo` flag.
The Swift driver rejects platforms that don't support Scudo using an
existing mechanism in the Driver that is not part of this patch. This
mechanism is in swift::parseSanitizerArgValues(...)
(lib/Option/SanitizerOptions.cpp). The mechanism determines if a
sanitizer is supported by checking for the existence of the
corresponding sanitizer runtime library in the compiler's resource
directory. The Scudo runtime library currently only exists in the
Linux compiler resource directory. This results in the driver only
allowing Scudo when targeting Linux.
The new option `-sanitize-recover=` takes a list of sanitizers that
recovery instrumentation should be enabled for. Currently we only
support it for Address Sanitizer.
If the option is not specified then the generated instrumentation does
not allow error recovery.
This option mirrors the `-fsanitize-recover=` option of Clang.
We don't enable recoverable instrumentation by default because it may
lead to code size blow up (control flow has to be resumable).
The motivation behind this change is that today, setting
`ASAN_OPTIONS=halt_on_error=0` at runtime doesn't always work. If you
compile without the `-sanitize-recover=address` option (equivalent to
the current behavior of the swift compiler) then the generated
instrumentation doesn't allow for error recovery. What this means is
that if you set `ASAN_OPTIONS=halt_on_error=0` at runtime and if an ASan
issue is caught via instrumentation then the process will always halt
regardless of how `halt_on_error` is set. However, if ASan catches an
issue via one of its interceptors (e.g. memcpy) then `the halt_on_error`
runtime option is respected.
With `-sanitize-recover=address` the generated instrumentation allows
for error recovery which means that the `halt_on_error` runtime option
is also respected when the ASan issue is caught by instrumentation.
ASan's default for `halt_on_error` is true which means this issue only
effects people who choose to not use the default behavior.
rdar://problem/56346688
This change allows the swift driver to link the ubsan runtime if
`-sanitize=undefined` is specified.
This is useful for sanitizing linked Objective-C code.
Similarly to Clang, the flag enables coverage instrumentation, and links
`libLLVMFuzzer.a` to the produced binary.
Additionally, this change affects the driver logic, and enables the
concurrent usage of multiple sanitizers.
With this patch different sanitizers (tsan/asan) will be enabled or
disabled on the driver level on a particular OS depending on whether
the required library is present.
The current patch only supports Darwin architectures, but Linux support
should not be hard to add.
"Sanitizer Coverage" with a new flag ``-sanitize-coverage=``. This
flag is analogous to Clang's ``-fsanitize-coverage=``.
This instrumentation currently requires ASan or TSan to be enabled
because the module pass created by ``createSanitizerCoverageModulePass()``
inserts calls into functions found in compiler-rt's "sanitizer_common".
"sanitizer_common" is not shipped as an individual library but instead
exists in several of the sanitizer runtime libraries so we have to
link with one of them to avoid linking errors.
The rationale between adding this feature is to allow experimentation
with libFuzzer which currently relies on "Sanitizer Coverage"
instrumentation.
