作者：Koki Mitsunami 2021年6月24日
今年3月，Arm推出了下一代Armv9体系结构，具有越来越强大的安全性和人工智能（AI）功能。在安全性和调试方面最相关的改进之一是支持内存标记扩展（MTE），这是新armv9cpu的一个关键特性。MTE旨在减轻与内存相关的漏洞，以提高连接设备的安全性。在这篇博文中，我们将分享引入MTE背后的动机、对这项技术的概述以及它对开发人员的用处。
内存安全漏洞导致的安全漏洞
C/C++语言用于移动和客户端设备中的大多数最终用户软件，包括各种领域，如操作系统、机器学习（ML）库、游戏和嵌入式软件。这些语言之所以被广泛使用，是因为它们具有其他编程语言所不具备的特性。其中包括快速执行速度和直接操作内存地址的能力，这对于低级语言来说是必不可少的。另一方面，如果使用不当，直接操作内存地址的能力会导致系统故障。此故障还可能导致软件中存在漏洞。攻击者可能利用这些漏洞访问敏感信息，恶意改变程序的行为，甚至完全控制控制流。这些可能会造成广泛的损害——其中一些损害不能单用金钱来衡量。
用C/C++语言编写的代码中最重要的一类安全漏洞是对内存安全的侵犯。根据Google安全博客的一篇文章(https://security.googleblog.com/2019/05/queue-hardening-enhancements.html)，大多数Android漏洞都是由释放后使用（UAF）和越界（OOB）读/写造成的。
图1:Android中的漏洞
（来源-https://security.googleblog.com/2019/05/queue-hardening-enhancements.html）
MTE是与Google合作开发的，目的是检测现有代码库和新代码中的内存安全缺陷。由于谷歌最近宣布Android开源项目（AOSP）支持Rust编程语言来开发操作系统本身，一些特定的软件组件可能会过渡到更安全的语言。然而，MTE为庞大的C/C++代码生态系统提供了一个有效的解决方案。此外，MTE不仅对于操作系统开发人员，而且对于应用程序开发人员来说，都是一个很好的工具，因为它允许他们快速发现常见的内存错误，并加快他们的生产流程。
难以检测和修复内存安全错误
当软件意外访问超出其分配大小或内存地址的内存时，就会发生内存安全错误。一些内存安全错误的例子可以在这里找到。不幸的是，检测和修复这些错误通常非常困难，因为错误状态必须在要检测的代码中触发。这将需要大规模的测试工作，这将需要大量的时间和成本。Bug修复也是一个漫长而昂贵的过程。
图2：修复bug的步骤
（来源-https://security.googleblog.com/2021/04/rust-in-android-platform.html）
对于一个复杂的C/C++项目来说，只有少数人能够开发和检查修复程序并不少见。此外，即使他们投入了大量精力来修复这些bug，程序也可能无法得到修复。下图显示了Android内存安全漏洞的年代。这表明有些bug在首次引入后数年内仍未被发现和修复
图3:Android内存安全漏洞的时代
（来源-https://security.googleblog.com/2021/04/rust-in-android-platform.html）
而且，一个bug发现得越晚，这个过程的成本就越高，时间也就越长。因此，早期检测对于降低这些内存安全错误的风险至关重要。同样，内存安全漏洞不是Android特有的问题。MTE将减轻安全漏洞，帮助开发人员识别和修复这些漏洞，并阻止恶意攻击者利用这些漏洞。
MTE如何应对挑战
MTE提供了一种机制，允许我们在释放和越界类型的bug之后检测使用情况。而且，它的设计方式使大多数应用程序不需要修改源代码。
下图说明了MTE的概念。MTE的底层模型是一个“锁和钥匙”方案。这意味着，当内存被分配或释放时，它被赋予一个标记（锁）。然后所有对该内存的访问都必须由具有相同标记（钥匙）的地址进行。如果锁和钥匙不匹配，那么CPU将引发一个错误。
图4:MTE中的锁和钥匙方案
对于图中的前两个指针，钥匙与访问位置的锁匹配。使用这些指针的访问将正常成功。但是，对于最后两个指针，钥匙与访问位置的锁不匹配。这被捕获为标记检查失败。通过这种机制，很容易检测到难以捕获的内存安全错误。这意味着即使是极少数的bug一旦被触发也会立即被检测到，这也有助于一般的调试。更多信息可以在架构文档页面中找到。另外，这两篇关于AnandTech和半导体工程的文章，以及这篇关于MTE的白皮书，为MTE提供了极好的介绍。在MTE中，有堆标记和堆栈标记，处理代码的方式略有不同。在这个博客中，我们主要讨论堆标记。
MTE在Android中的应用
MTE内置于第一代ARMV9 CPU中，将于明年上市。android12引入了对使用MTE的软件支持。因此，目前还没有支持MTE的硬件，但是您可以通过在固定虚拟平台（FVP）环境中使用模拟来了解它的工作原理。FVP被设计用来精确地模拟一个完整系统的工作，用于软件开发。这在开发人员为MTE等新技术编写代码时尤其有用。预先构建的FVP模型可从Arm开发者网站“Armv-A Base RevC AEM FVP”中获得。要在FVP上构建和运行支持MTE的Android，您可以按照本页的说明进行操作。请注意，这些指令使用AOSP的主分支，这不是Google支持的版本。
为了演示MTE在真实案例中的工作方式，我们在libjpeg-turbo库中选择了一个漏洞（CVE-2020-13790），该漏洞于2020年修复。libjpeg-turbo是Android中使用的JPEG图像编解码器。该漏洞是加载格式错误的图像文件时基于堆的缓冲区溢出。
我们在FVP环境中复制了这个bug，并确认MTE可以很容易地检测到它。当MTE发现一个bug时，进程将以分段错误终止。它的崩溃转储可以通过Android的logcat命令打印出来。下面是logcat命令输出的崩溃报告的片段。如果您使用的是来自androidstudio的调试器，则会以与任何其他崩溃类似的方式捕捉到这种情况。
输出1:MTE崩溃报告的示例片段
您可以看到MTE检测到某个地址发生了缓冲区溢出。此外，崩溃报告还显示进程id、线程id、崩溃原因、坏内存访问地址。随后是接收信号时CPU寄存器的内容以及堆栈帧的回溯。用户可以使用这些信息比以前更容易地定位bug，并开始修复它。有关logcat输出中崩溃转储的基本信息可以在这里找到。例如，使用如下所示的addr2line命令可以很容易地识别bug文件中的函数名和位置。未来真正的Android设备可能会在报告中以一种稍微精巧的方式显示位置。
输出2：确定错误位置
降低开销和提高报告准确性之间的权衡
您可能想知道MTE的性能开销是多少。为此，该体系结构提供了同步和异步模式来报告标记比较失败。下表比较了这两种模式的功能。
同步模式
适合开发
•确定导致故障的确切说明和地址
•轻微的性能影响
异步模式
适合部署
•生产系统可接受的性能开销
•关于故障发生地点的信息不太准确
表1:MTE报告标签比较失败的两种模式
同步检查使调试更简单，因为它允许您识别导致故障的精确指令和地址。但是，同步检查对性能的影响稍大一些。性能开销因处理器的类型而异，但在开发环境中，性能影响是完全可以接受的。但是，它对于部署来说可能太高了。另一方面，异步模式成本较低，跨工作负载和测试基准的性能开销估计为1-2%。这意味着即使在生产系统上，异步检查也是可以接受的。尽管异步检查提供的关于标记比较失败发生位置的信息不太准确，但它可以提供一些缓解措施，并可用于分析。分析允许识别问题区域，缩小bug的搜索范围。MTE的灵活性允许在较低的开销和更准确的报告之间进行权衡。请注意，绩效管理费用数字在未来的发展中可能会发生变化。
有几种针对内存安全的软件缓解技术，如ASan和HWASan。然而，这些都是昂贵的性能方面。这使得它们不适合广泛部署。MTE的目标是即使在生产代码中也能以较少的性能下降工作。这一点非常重要，因为在生产代码中出现的bug有时不会出现在开发代码中。MTE发现了更多的bug，而花费只是成本的一小部分。
在Android生态系统中更广泛地部署MTE
Android平台对MTE的支持将在2021年底/2022年初发布带有MTE的芯片时完成。此外，Arm开发者网站（https://developer.arm.com/architectures/cpu-architecture/a-profile?_ga=2.256790923.1616116652.1625373864-418006553.1606625914）上的支持材料包含大量有趣的见解和信息，以帮助合作伙伴和开发者提高内存安全性。我们真的很兴奋，MTE可以通过检测以前不容易发现的错误来提高内存安全性。我们期待MTE在Android软件和硬件生态系统中得到更广泛的部署。
MTE很可能是2021年10月19日至21日举行的Arm DevSummit上讨论的众多主题之一。注册将在7月26日之前开放，但您可以注册您的兴趣。
