内容摘要：谷歌 Chrome 安全团队称其一直在致力于改善 Chrome 浏览器的内存安全；近期，该团队正在研究使用 heap scanning 技术来提高 C++ 的内存安全。虽然从内存安全方面出发，Rust

谷歌 Chrome 安全团队称其一直在致力于改善 Chrome 浏览器的谷歌高内存安全；近期 ，该团队正在研究使用 heap scanning 技术来提高 C++ 的正寻内存安全 。

虽然从内存安全方面出发，求提Rust 当下可能更受大众喜爱。内存但 Chrome 安全团队认为，安全尽管人们对比 C++ 具有更强内存安全保证的谷歌高其他语言有兴趣 ，但在可预见的正寻未来 ，像 Chromium 这样的求提大型代码库将使用 C++
。鉴于此
，内存Chrome 工程师已经找到了使 C++ 更安全的安全方法
，以减少缓冲区溢出和 use-after free (UAF) 等与内存相关的高防服务器谷歌高安全漏洞 。数据表明，正寻这些漏洞占所有软件安全漏洞的求提 70%。

复制auto* foo = new Foo();

delete foo;

// The 内存memory location pointed to by foo is not representing

// a Foo object anymore, as the object has been deleted (freed).

foo->Process();1.2.3.4.5.

如上示例，当应用程序使用的安全内存被返回到底层系统，但指针指向一个过期的对象时
，就会出现一个被称为悬空指针（dangling pointers）的情况，通过它进行的任何访问都会导致 UAF 访问。在最好的情况下，此类错误会导致 well-defined 的源码下载崩溃；在最坏的情况下，它们会造成可以被恶意行为者利用的破坏。 

在较大的代码库中，UAF 通常很难被发现，因为对象的所有权是在不同组件之间转移的。这个问题非常普遍 ，以至于到目前为止
，工业界和学术界都在频繁地针对其提出缓解策略。而 Chrome 中 C++ 的使用也没有什么不同，源码库大多数高严重性安全漏洞都是 UAF 问题。近期发布的 Chrome 102 中，就修复了一个关键的 UAF 问题 ，且八个高危漏洞中有​六个是 UAF。

为了解决这一问题
，Chrome 方面已经使用了各种技术手段；包括 C++ 智能指针（如 MiraclePtr​）、编译器中的静态分析、动态工具（如 C++ sanitizers ）、代码模糊器 ，以及一个名为  Oilpan 的 C++ 垃圾回收器。云计算Oilpan、MiraclePtr 和基于智能指针的解决方案需要大量采用应用程序代码 。

此外 ，谷歌还探索了另一种方法：内存隔离（memory quarantine）
。基本思路是将 explicitly freed memory 放入隔离区 ，并且仅在达到特定安全条件时才使其可用 。Chrome 安全团队在博文中总结了在 Chrome 中实验隔离和 heap scanning 的历程
。

工作原理在于  ，用隔离和 heap scanning 保证 temporal safety 的主要思想是避免重用内存，直到证明没有更多的（悬空的服务器租用）指针指向它
。为了避免改变 C++ 用户代码或其语义，提供 new 和 delete 的内存分配器被拦截 。

在调用删除时
 ，内存实际上被放入隔离区，无法再用于应用程序的后续新调用 。“在某些时候触发了 heap scan ，它扫描整个堆，就像垃圾回收器一样，以查找对隔离内存块的引用  。那些没有从常规应用内存中获得引用的块被转移回分配器，在那里它们可以被重新用于后续的建站模板分配。”

根据介绍，谷歌的 heap scanning 由一套被命名为 StarScan（简称为 *Scan）的算法组成。他们将 *Scan 应用于渲染器进程的非托管部分，使用 Speedometer2 评估性能影响，并尝试了不同版本的 *Scan 。

测试结果表明，*Scan 的一个基础版本造成了 8% 的内存回归。“所有这些开销从何而来？不出所料，heap scanning 极其受 memory bound 影响 ，因为扫描线程必须遍历和检查整个用户内存的引用” 。在进行了多方面优化之后，Speedometer2 回归从 8% 降低到了 2%。此外，有关内存消耗的测量结果则表明，渲染进程中的扫描使内存消耗减少约 12% 。

MTE（内存标签扩展，Memory Tagging Extension）是 ARM v8.5A 架构上的一个新扩展 ，有助于检测软件内存使用中的错误；这些错误可以是 spatial errors（如 out-of-bounds accesses） ，也可以是 temporal errors（use-after-free）。谷歌方面获得了一些支持 MTE 的 actual hardware ，并在渲染器过程中重新进行了实验。结果表明，虽然 MTE 和 memory zeroing 会带来一些成本 ，但 Speedometer2 中的内存回归约为 2%。实验还表明
，在 MTE 之上添加 *Scan 没有可衡量的成本。 

Chrome 安全团队最后总结称
，C++ 可以编写出高性能应用程序，但需要付出安全性方面的代价。Hardware memory tagging 可以修复 C++ 的一些安全缺陷，同时保持高性能。“我们期待在未来看到更广泛地采用 Hardware memory tagging，并建议在 Hardware memory tagging 之上使用 *Scan 来修复 C++ 的 temporary memory safety 
。使用的 MTE 硬件和 *Scan 的实现都是 prototypes，我们预计仍有性能优化的空间 。”

本文转自OSCHINA

本文标题：谷歌正寻求提高 C++ 内存安全

本文地址：https://www.oschina.net/news/198093/google-c-memory-safety