[llvm-dev] PSA: the future of compiler-rt’s Scudo

[Kostya Kortchinsky via llvm-dev]

Greetings,

compiler-rt hosts a hardened usermode memory allocator, named Scudo (
https://llvm.org/docs/ScudoHardenedAllocator.html). It aims at providing
additional mitigation against heap-based vulnerabilities, while maintaining
good performance. It leverages sanitizer_common code, and provides
allocation primitives via the usual C/C++ functions.

Up until now, Scudo was mostly used (as far as I can tell) by linking the
library (dynamically or statically) to binaries, thus overriding the
platform’s C/C++ library allocation functions.

A new usage scenario has emerged: replacing the actual libc allocator on a
platform (namely Fuchsia). The current organization of the code, and some
design choices, do not fit the requirements for such a use case (as
expressed by Fuchsia, but legitimate points for all use): the code should
be “production ready”, ideally small and self contained, carefully reviewed
for potential performance impact, and obviously security as well. With no
disrespect intended towards sanitizer_common, this can’t be the case with
such a dependency.

After multiple discussions with the stakeholders, a standalone (eg: no
sanitizer_common dependency) version of Scudo appeared to be the solution
that would allow us to move forward. This meant rewriting parts of
sanitizer_common that are currently used by Scudo (thus: some code
duplication).

An early plan was to move to our own googlesource repository (or the like),
but Chandler suggested we stay in compiler-rt, as a separate directory that
could be a slice of the new git monorepo. This appeared to be acceptable to
everybody involved (Chandler, Kostya S., Petr, Roland, Julia), and is now
the plan of record. Once the standalone version is in, the non-standalone
Scudo will likely be deprecated, although this part hasn’t been formalized
yet.

We recognize the full implications of the decision in terms of feature
sharing with sanitizer_common (or lack thereof), potential further
duplication, etc., but the benefits outweigh the disadvantages.

We are time constrained, and I would like to start committing code as soon
as possible, but I am open to hearing opinions and feedback about the plan.

Thank you for reading,

Kostya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190114/12e00e0f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4845 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190114/12e00e0f/attachment.bin>