[llvm-dev] PSA: the future of compiler-rt’s Scudo (original) (raw)

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 15 14:39:11 PST 2019

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 sanitizercommon 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 sanitizercommon, this can’t be the case with such a dependency. After multiple discussions with the stakeholders, a standalone (eg: no sanitizercommon dependency) version of Scudo appeared to be the solution that would allow us to move forward. This meant rewriting parts of sanitizercommon 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 sanitizercommon (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>

More information about the llvm-dev mailing list