G.O.S.S.I.P 阅读推荐 2022-06-17

今天你是在关注江南造船厂的新航空母舰下水，还是在准备6·18大促把自己的手剁掉呢？让我们暂时忘记学术论文，去看一下Google安全博客上的一篇关于C++代码内存安全增强的讨论随笔吧

作为宇宙中首屈一指的内存安全漏洞大户，Google自家的Chrome可以说这些年养活了一众安全研究人员，估计开发团队和安全部门都会收到来自CEO“劈柴”的压力。因此，在Chrome代码中，Google也在不停实验很多新的安全防护特性，而最近引入的就是今天文章的主角——heap scanning technologies

作为主要的竞争对手，Firefox那边正在积极推进Rust代码，而G家这边可能觉得用Rust有辱尊严，因此仍然希望能在C++代码的基础上直接“缝缝补补又三年”。可是那些经典的内存破坏漏洞（诸如UAF）就始终没法得到完全发现和修复，不管是基于智能指针，还是基于编译器静态分析和代码级别的动态sanitization（别忘了还有我们在今年SP上发表的G.O.S.S.I.P 学术论文特别推荐 2022-03-07 内存破坏猎手——Goshawk），这些努力都在海量（低质量）代码面前有点杯水车薪的感觉。也许是受到我们的CryptoMPK论文（https://zhuanlan.zhihu.com/p/389307848）的影响（或者是上海2022魔幻的春夏之交的影响），Google最近也开始尝试将heap memory单独隔离，思路很简单粗暴，就把所有的new和delete都重载，然后引入一个新的堆内存分配器。所有要释放的内存，先隔离14天，如果核酸都为阴性才允许重新使用

大家不要觉得这种思路简单就看不起，工程实践上，往往simple but powerful是最好的东西，Google的研发人员总结了一系列内存分配和释放过程中对可能的问题进行扫描的策略，将其归结为所谓的StarScan（*Scan）算法，来解决被隔离的内存怎么样才算安全，何时可以解封被重用的问题（虽然听起来和GC很像，在随笔文章中也并没并看出来什么新的技术，我们只能寄希望于Google团队的工程能力）。

和学术论文不同，博客文章往往不够严谨， 这篇文章也有这个毛病（虽然是Google博客背书），作者给*Scan算法画了很多饼，对优化策略描述是语焉不详——“On top, we applied several micro optimizations to speed up and eliminate computations: we use helper tables for pointer filtering; rely on SIMD for the memory-bound scanning loop; and minimize the number of fetches and lock-prefixed instructions.” 当然，引入这种隔离机制不仅带来了运行时的性能下降（尽管号称能优化到只有2%），还增加了12%的内存开销（嗯，本来Chrome就是内存杀手）。【这里我们发现国内的一些机翻文章根本就是牛头不对马嘴，把regression生硬地翻译为“减少”，实际上应该是“使之倒退”，也就是说，原文中使用了regression和regress的地方，是在表达*Scan算法让实际运行的性能“恶化”了xx%】

最后，作者还针对pointer authentication，特别是在ARM平台上可以使用Memory Tagging Extension（MTE）特性的情况进行了讨论（MTE的基本原理如下图所示，就是给每块16字节的内存加一个4bit的tag）。

但是这篇博客里面讨论针对MTE的memory tag碰撞攻击的描述实在是有点含混不清，只是提到*Scan算法能在MTE的基础上再增加一步检查，两者结合起来，一方面减少了内存的开销，另一方面也为MTE的使用进一步增强了安全性。这里真是无力吐槽这篇blog文章的插图水平，如果是学术投稿，小编我肯定是要拒了它

最后，对Google画的这个饼，小编表示只能拭目以待，同时要批评一下国内很多对这篇文章的机翻，很多细节都被歪曲得不成样子，还不如学我们囫囵吞枣

文章（需要翻墙）：

https://security.googleblog.com/2022/05/retrofitting-temporal-memory-safety-on-c.html

原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2022-06-17