作者 | Sergio De Simone

译者 | 平川

策划 | Tina

对于如何使 C++ 成为一种类似 Rust 及其他内存安全语言（MSL）的安全语言，C++ 专家、ISO C++ 委员会主席 Herb Sutter 在最近的一篇文章中表达了他的看法。他的方法包括依赖工具（与其他 MSL 一样）、推广安全语言特性、不安全特性需要显式启用等等。

Sutter 指出，为了使 C++ 变得更加安全，首先要解决 4 种主要的内存安全相关的漏洞。实际上，在总共 12 类与内存安全相关的漏洞中（约占所有 CVE 的 70%），有 4 个源于越界读、越界写、空指针解引用和访问已释放内存。

根据 Sutter 的说法，C++ 已经对编写安全代码提供了广泛的支持，而且 C++ 文献早就确定了用于实现这一目标的关键规则。不过，他认为，作为一种关键的语言特性，C++ 应该严格执行这些规则，只有当程序员明确选择不遵循标准规则时，才可以使用不安全行为。

默认启用安全规则不会限制这门语言的能力，但若要采用非标准实践就需要显式做出选择，从而减少无意的风险。它可以随着时间的推移而进化，这一点很重要，因为 C++ 是一种活的语言，而敌手会不断地改变他们的攻击手法。

Sutter 还描述了一些错误的问题和认识。他指出，大多数高严重性 CVE 都与内存安全无关（尽管越界写是罪魁祸首）；MSL 也有 CVE；MSL 也依赖于静态分析程序和杀毒程序等工具。因此，最终目标不可能是让 C++ 程序完全摆脱与内存安全相关的 CVE，也不是在不依赖工具的情况下强制执行内存安全规则或者使 C++ 代码在形式上可证明。

在他的文章中，Sutter 重启了一个关于 C++ 内存安全的讨论，那是由 2023 年美国国家安全局网络安全信息表引发的，它建议人们远离 C/C++ 以及其他内存不安全的语言。

作为对 NSA 报告的回应，Bjarne Stroustrup 表达了他的观点，即 C++ 可以像 Rust 一样安全，而且不用像后者那么复杂：

C++ 核心指南旨在为那些需要静态类型安全和资源安全的 C++ 开发人员提供这方面的保证，而且不会破坏代码库，他们可以在没有这类强力保证或不额外引入工具链的情况下对代码库进行管理。

在这里，Stroustrup 含蓄地指出，ISO 委员会正在开展有关 C++ profilse 的工作，其目的是使逐步采用更安全的行为并在编译时强制执行安全规则成为可能。

“Profile”是一组确定性的（deterministic）、便于强制执行（portably enforceable）的规则子集（即限制），旨在实现特定的保证。“确定性”意味着它们只需要局部分析，并且可以在编译器中实现（尽管它们不必如此）。“便于强制执行”意味着它们就像语言规则一样，程序员可以使用不同的强制执行工具，而且不同的工具对于相同的代码会给出同样的答案。

特别地，C++ profiles 包括类型安全、边界安全和生命周期安全。根据 Stroustrup 的说法，符合 profiles 规则的代码是安全的，因为其中包含安全保障。

Stroustrup 对 NSA 报告的批评引起了有些人的注意，Jimmy Hartzell 就提出了一些有根据的批评，其中包括 C++ 还不是一种内存安全的语言，线程安全等领域的考虑还比较欠缺，而 Rust 已经有很多与之相关的机制。

现在，甚至在系统编程领域，C++ 也受到 Rust（一种强大的内存安全编程语言，而且可以避免 C++ 的许多问题）的威胁。即使是在 C++ 非“遗留”的领域，也有了可行的、内存安全的替代方案，而且没有像 C++ 那么多的技术债务。

回到 Sutter 的观点，和 Stroustrup 一样，他也相信，profiles 是使 C++ 更安全的一个关键特性，可以将 C++ 代码中类型 / 边界 / 初始化 / 生命周期相关的 CVE 减少 98%，而又不限制 C++ 的能力：

我不希望 C++ 限制我的表达能力。我只是希望 C++ 能默认执行我们已经熟知的安全规则和最佳实践，如果我想的话，我也可以明确地选择不遵守。然后，我仍然可以使用完全现代化的 C++……只是更友善一些。

在文章的最后，为了帮助 C++ ISO 委员会达成 98% 的目标，他提出了一些广泛而具体的建议。相关细节，错过可惜。

原文链接：