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

Kostya Serebryany via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 15 14:40:48 PST 2019

On Mon, Jan 14, 2019 at 1:57 PM Kostya Kortchinsky via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

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

Yep, I'd rather have scudo in compiler-rt as Kostya K suggests it, than not
have it.
It's unfortunate that we have to essentially fork parts of compiler-rt into
a separate directory (still in compiler-rt),
but all alternatives we looked at are not any better.

> Thank you for reading,
> Kostya
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190115/254ff6aa/attachment-0001.html>

More information about the llvm-dev mailing list