Hi LLVM Community,
We propose forming a new working group within the LLVM project to focus on developing (and using) memory safety bug-prevention techniques. This would bring together LLVM contributors and users to focus on things like runtime hardening, language extensions, and general improvements to LLVM’s C++ toolchain (Clang, libc++, LLVM, etc).
We tentatively plan to have the first meeting on Wednesday, February 19, 2025 (exact time and other details will follow) and are eager to hear your feedback on the proposal.
Goals and non-goals
This group will discuss safety features and techniques that are readily available or can be implemented with relatively low effort, and those that can be applied in an existing codebase with low cost. We want the group to be pragmatic and look at incrementally-deployable mitigations that provide minimal performance hit and are otherwise practical and can be used today.
Examples of topics that are in-scope for this group:
- Memory safety features in Clang that are actively deployed or currently developed:
- Language extensions (-fbounds-safety) and warnings (
-Wunsafe-buffer-usage) for spatial safety. - Hardened libc++ for spatial safety.
- Typed allocators for temporal safety.
- Pointer authentication for temporal and spatial safety.
[[lifetimebound]]and similar annotations for temporal safety. Other extensions for lifetimes.
- Language extensions (-fbounds-safety) and warnings (
- Cataloging existing safety features, providing documentation, establishing and instilling best practices and good defaults for safety mitigation.
- Sharing and generalizing experience of deploying existing safety features.
We also propose to start by focusing specifically on memory safety. We have observed that this is where the majority of energy is being invested across the industry. We still anticipate this group getting into other areas over time too (e.g. thread safety), after the initial topics will run out of steam, while acknowledging that there may be some overlap already.
We should attempt to prioritize techniques that eliminate entire bug classes or make them unexploitable with high assurance, over probabilistic measures, where feasible.
Non-goals
This is not a security or language research group. We would like to keep the group focused on pragmatic and practical outcomes and avoid getting into areas that require significant research or too much engineering investment.
Example topics that are out of scope:
- Borrow checker, garbage collection, other large and non-incremental language overhauls.
- Efforts requiring major backwards-incompatible language extensions.
Relation to LLVM Security Group
As mentioned above, this group does not aim to find or address security vulnerabilities in LLVM itself. LLVM Security Group is already responsible for that and we do not intend to overlap with their responsibilities. If the Safety Working Group discovers vulnerabilities in LLVM itself, we will follow the procedures for vulnerability disclosure and inform the LLVM Security Group.
As much of the work being done here pertains to security, there will be discussions about how we handle bypasses or newly introduced weaknesses. We will coordinate with the LLVM Security Group to ensure we’re following best practices and have the ability to notify users of important fixes.
All the communications of this group will stay open and anyone would be welcome to participate in it. We would also want to create a separate low-frequency communication channel for sharing important news, e.g. when the new hardening technique ships or critical fixes to existing hardening is available (likely through Discourse, but concrete details are TBD).
Participants
We encourage anyone interested from the LLVM community to participate in the group. The meetings and communications will be public. We have circulated the idea beforehand and identified the following initial members of the LLVM Community that would be interested in participating in the kick-off:
* Arlie Davis <ardavis@microsoft.com> / Microsoft
* Brian Gaeke <bgaeke@nvidia.com> / Nvidia
* Dan Liew <dan@su-root.co.uk> /Apple
* Devin Coughlin <dcoughlin@apple.com> / Apple
* Ilya Biryukov <ibiryukov@google.com> / Google
* Joe Bialek <jobialek@microsoft.com> / Microsoft
* Jon Bauman <jonbauman@rustfoundation.org> / Rust Foundation
* Josh Stone <cuviper@gmail.com> / RedHat
* Max Shavrick <mxms@google.com / Google
* Miguel A. Arroyo <miguel@arroyo.me>
* Ravi Kandhadai Madhavan <rkandhadaimadhav@apple.com> / Apple
* Vivek Kale <vlkale@sandia.gov> / Sandia National Labs
* Yael Meller <yael@nvidia.com> / Nvidia
* Yeoul Na <yeoul_na@apple.com> / Apple
* Yitzhak Mandelbaum <yitzhakm@google.com> / Google
Organizational details
Regular Meetings. We propose to start meeting every 2 weeks for 1 hour. After 4 meetings, we will reflect on progress and adjust the long-term schedule, structure, etc.
Communications. We will keep public meeting notes, Discourse topics and Discord Channel for general discussions. We will also create a low-frequency topic on Discourse to share important progress and news.
Initial discussion topics
We propose to start by focusing on a few topics that we expect to produce most fruitful outcomes in the short term. We will adjust as needed after a few initial rounds to see where this would come from.
- Formulating best practices and sharing experiences across the industry for available mitigations.
- Bug prevalence.
- Deployed mitigation techniques and their effectiveness.
- Performance and other environmental constraints, trade-offs they entail.
- Discussing and coordinating active developed mitigations
- Spatial and temporal safety techniques from examples in the Goals and non-goals section.
- Tooling for automated warning mitigation and code migration.
