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

[Chandler Carruth via llvm-dev]

FWIW, my reasoning for suggesting keeping it in `compiler-rt` is that I
somewhat wish we had a more general structure like `runtimes` with all of
our runtimes in it.

Maybe we will get there if/when we can restructure things easily (post git
migration, in whatever form it takes).

For now, it just didn't seem worth the cost of adding a repository sibling
to `compiler-rt`, `libcxx`, `libcxxabi` just for Scudo, so I'd toss it
under `compiler-rt`. If that causes problems, can always create a repo for
it. Mostly, it complicates the github migration scripts I suspect.

-Chandler

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.
>
> 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/b3f86eb3/attachment.html>