carbon-lang/proposals/p0196.md

Language-level safety strategy

Pull request

Table of contents

• Problem
• Background
• Proposal
• Open question: probabilistic checks in the hardened build mode

Problem

Carbon needs to have a clear and consistent strategy for approaching the problems of language-level safety. These problems have been persistent and growing sources of both bugs and security vulnerabilities in C and C++ software. Failure to effectively and carefully address safety concerns is likely to undermine any hope of Carbon being a successful path forward for today's C++ users.

Background

• Fearless Security: Memory Safety
• A proactive approach to more secure code
• Chromium memory safety
• MemSafe
  • Notably introduces the terms "spatial" and "temporal" safety.

Proposal

We propose a safety strategy for Carbon that aims for incrementally increasing the compile-time proven safety while allowing for dynamic checks to cover what remains. It also prioritizes dynamic safety checks that are amenable to being optimized away or being manually disabled for performance-critical use cases where the added dynamic protections are not a viable trade-off.

Open question: probabilistic checks in the hardened build mode

This proposal explicitly discourages probabilistic checks in the hardened build mode because they won't reliably prevent security attacks. Does the core team believe that we should put a cap on how much performance should be sacrificed for safety, putting more emphasis on probabilistic methods that would allow more attacks through?

For example, heap use-after-free detection with 100% accuracy is expected to be a significant expense for hardened builds. MarkUs is estimated to cost 10-50% CPU and 25% RAM in order to catch 100% of issues. For comparison, MTE is estimated to cost 0-20% CPU and 3-6% RAM in order to catch 93% of issues.

The CPU and RAM cost of MarkUs is significant, even by comparison with other techniques, and costs will add up as more safety is added. 93% is a reasonably high detection rate for an performance-efficient, probabilistic technique. Would the core team expect to use MTE instead MarkUs in hardened builds?