<div dir="ltr">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.<div><br></div><div>Maybe we will get there if/when we can restructure things easily (post git migration, in whatever form it takes).</div><div><br></div><div>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.</div><div><br></div><div>-Chandler</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 14, 2019 at 1:57 PM Kostya Kortchinsky via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Greetings,</div><div><br></div><div>compiler-rt hosts a hardened usermode memory allocator, named Scudo (<a href="https://llvm.org/docs/ScudoHardenedAllocator.html" target="_blank">https://llvm.org/docs/ScudoHardenedAllocator.html</a>). 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thank you for reading,</div><div><br></div><div>Kostya</div><div><br></div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>