# Language-level safety strategy

<!--
Part of the Carbon Language project, under the Apache License v2.0 with LLVM
Exceptions. See /LICENSE for license information.
SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-->

[Pull request](https://github.com/carbon-language/carbon-lang/pull/196)

<!-- toc -->

## Table of contents

-   [Problem](#problem)
-   [Background](#background)
-   [Proposal](#proposal)
-   [Open question: probabilistic checks in the hardened build mode](#open-question-probabilistic-checks-in-the-hardened-build-mode)

<!-- tocstop -->

## 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](https://hacks.mozilla.org/2019/01/fearless-security-memory-safety/)
-   [A proactive approach to more secure code](https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/)
-   [Chromium memory safety](https://www.chromium.org/Home/chromium-security/memory-safety)
-   [MemSafe](https://doi.org/10.1002/spe.2105)
    -   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](https://docs.google.com/document/d/14-_JAMoMBIVgKOUi3iZIRMHJlAyT23kqSVR8wxJPk9M/edit)
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?
