铬项目发现70%的安全缺陷是内存安全问题

Chromium项目发现，大约70%的严重安全漏洞是内存安全问题。我们的下一个重大项目是从源头上防止此类错误。

大约70%的严重安全错误是内存不安全问题(即C/C++指针错误)。其中一半是免费后使用的漏洞。

(基于自2015年以来影响稳定渠道的912个高或严重严重安全漏洞进行分析。)。

这些错误均匀地分布在我们的代码库中，并且我们的高比例的非安全稳定性错误共享相同类型的根本原因。除了危及我们用户的安全，这些漏洞在我们修复和发货Chrome的方式上也有实际的成本。

Chrome的安全体系结构一直被设计成假定这些bug存在，并对代码进行沙箱保护，以防止它们接管主机。在过去的几年里，这种架构得到了增强，以确保网站彼此隔离。这一巨大的努力使我们-只是-保持在袭击者的前面。但是我们正在到达沙箱和场地隔离的极限。

一个关键的限制是进程是最小的隔离单位，但是进程并不便宜。尤其是在Android上，使用更多的进程会影响设备的整体健康状况：后台活动(其他应用程序和浏览器选项卡)被终止的频率要高得多。

我们仍有共享多个站点信息的进程。例如，网络服务是一个用C++编写的大型组件，它的工作是解析来自网络上任何狂人的非常复杂的输入。这就是我们在规则2策略中所称的“末日区域”：网络服务是一个庞大的软目标，并且存在严重的漏洞。

正如站点隔离通过将呈现器绑定到特定站点来提高安全性一样，我们可以想象对网络服务也是如此：我们可以有许多网络服务进程，每个进程都绑定到一个站点或(最好是)一个源。这将是美好的，并将极大地降低网络服务危害的严重性。然而，它也将爆炸性地增加Chromium所需的进程数量，并引发所有效率问题。

同时，我们对规则2的坚持阻碍了Chrome开发者发布功能，因为有时启动一个新的过程来处理不可信的数据已经太昂贵了。

我们不能再从更多的流程或更强大的沙箱中获得足够的创新(尽管这样的事情仍然是必要的)。

因此，保持优势的最便宜的方法是在源头上压制bug，而不是稍后尝试控制它们。

我们正在采取一切必要的手段来解决内存不安全问题--大规模修复各类错误，而不是仅仅控制它们，包括：

std和abseil假定调用方“对于速度”是正确的，但可以修改它们，以便使用实现更改(Abseil)和编译时标志(LLVM Libcxx)执行基本检查。

泛化Blink的C++垃圾收集器，并更广泛地使用它(从PDFium开始)。

由LLVM插件和预提交检查定义和实施。特别是，我们觉得可能有必要禁止来自C++的原始指针。

对C++开发人员体验进行了重大更改，并对性能产生了一些影响。(例如，没有原始指针、边界检查和垃圾回收。)

一种设计用于编译时安全检查的编程语言选项，运行时性能影响较小-但显然在C++和新语言之间架起桥梁是有代价的。