共计 1458 个字符，预计需要花费 4 分钟才能阅读完成。
始终以来，网络浏览器都会受到来自黑客的攻打，谷歌曾试图用沙箱解决这个问题，但因为性能问题停顿碰壁。因而，近日 Chrome 平安团队发文发表正在思考应用内存平安语言 Rust 重写或开发 Chrome 的局部模块。
家喻户晓，内存平安是寰球软件工程界都须要认真对待的问题。有数据显示，去年 Chrome 工程师们剖析了自 2015 年以来 Chrome stable 分支中修复的 912 个安全漏洞，这些破绽的严重性评级为“高”或“重大”，而这些重大安全漏洞里，有 70% 以上都是内存平安问题。也就是说，C 或 C++ 语言中的指针谬误会导致内存被误会。
Chrome 平安团队示意，只管与黑盒测试技术相结合仍是 Chrome 的次要“防线”，但这仿佛曾经达到了极限，再也无奈靠这一个策略来抵制住疯狂的攻打。
Chrome 平安团队认为，内存平安问题的存在，对于团队来说既是挑战也是机会，因为许多 bug 都有雷同的本源，这意味着他们能够在一个步骤中打消大部分 bug。
对此，Chrome 平安团队始终在摸索，并通过以下 3 大路径来解决：
- 通过编译时查看指针是否正确，使 C++ 更平安。
- 通过运行时查看指针是否正确，使 C++ 更平安。
- 考察局部代码库应用内存平安语言的状况。
“编译时查看”，意味着在 Chrome 构建过程中或 在 Chrome 进入用户设施前，平安就失去了保障。而“运行时”是指 Chrome 平安团队在用户的设施上运行 Chrome 时进行查看，因为“运行时查看”会导致性能损失（只管查看指针的正确性在内存和 CPU 工夫上的耗费是微不足道的，如果有数百万个指针加起来的话会加剧影响），且 Chrome 的性能对数十亿用户十分重要，许多用户应用的是没有太多内存的低功耗挪动设施，因而这些查看的减少将导致网络速度变慢。
所以在现实状况下，Chrome 会抉择以上 3 个路径的选项 1——在编译时使 C ++ 更平安。但可怜的是，语言理念并非这样设计的。所以 Chrome 也有了选项 2 和 选项 3——使 C ++ 更平安（但速度较慢），或开始应用不同的语言（Chrome Security 正在试验这两种办法。）
同时，Chrome 平安团队还介绍了其在 C++ 平安解决方案方面的重大投资——如 PTR 和 ABSL/STL 强化模式。在每种状况下，Chrome 都心愿打消可利用的安全漏洞中相当大的一部分，但他们也预料到了一些性能损失。
同时，Chrome 平安团队还将摸索将来是否能够为 Chrome 的某些局部应用内存平安语言，比极具竞争力的 Rust 语言，（很大水平上）是编译时平安的。也就是说，Rust 编译器在代码达到用户设施之前就发现了指针谬误，因而没有性能损失。然而，对于 Chrome 是否可能使 C++ 和 Rust 充沛协同工作，还有一些悬而未决的问题。即便 Chrome 今天就开始在 Rust 中编写新的大型组件，Chrome 也不可能在几年内就能把大部分大部分安全漏洞给全副打消。所以是否让语言边界足够洁净，以便能够应用 Rust 编写局部现有组件？Chrome 平安团队 临时也无法回答这个问题。
对于开发者团队来说，平安与破绽就像是“猫鼠游戏”，随着攻击者的一直“翻新”，浏览器也必须要装置新的进攻零碎能力放弃当先。只管 Chrome 已在沙箱和站点隔离根底上，投资建设了更弱小的多过程体系结构，但有时也是防不胜防。
目前，Chrome 平安团队曾经开始在 Chrome 源代码树中进行无限的、非面向用户的 Rust 试验，因为目前还处于试验阶段，因而暂未在 Chrome 的生产版本中应用。
参考链接：
https://security.googleblog.c…
