Armv9-A：如何利用MTE和FF-A功能创建最先进的TEE
安全之安全(security²)博客目录导读
目录
一、什么是MTE？
二、Trustonic如何在Kinibi 600中使用MTE？
三、什么是FF-A？
四、FF-A如何在Kinibi 600中工作？
五、总结
说明：本文为转载文章，来自Trustonic
Armv9-A于2021年3月推出，代表了ARM对未来十年未来3000亿芯片计算平台的愿景。上一次我们讨论了Armv9-A中添加的一些关键扩展，如无特权访问[PAN]、指针身份验证码[PAC]、分支目标标识[BTI]等。
然而，从Trustonic的角度来看，Armv9-A最重要的两个功能是其内存标记扩展[MTE]和构建Cortex-A固件框架[FF-a]的安全管理程序。这是因为这两个功能都构成了我们Kinibi 600操作系统[OS]的关键元素，有助于在正确的环境中形成可信执行环境[TEE]。
考虑到MTE和FF-A的复杂性，我们将在这文章中更深入地研究这些功能，解释为什么我们要在Kinibi 600中实现它们。
一、什么是MTE？
Arm在Armv8.5-A架构更新中引入了MTE，它是一种新的硬件机制，使用户能够标记虚拟内存的区域。
当一个内存区域被标记时，它只能通过包含相同标记的虚拟地址访问。如果使用不同的标签访问该区域，则中央处理单元[CPU]会阻止访问并中止。
MTE硬件成本相当大，因此有合理的限制：一个操作系统的每个应用程序可以使用16个不同的MTE标签，并且内存区域的最小大小是16个字节。
该规则已经适用Linux应用程序，可以使用mmap（）和PROT_MTE来分配支持标记的内存区域。clang工具链也支持MTE，可以使用新的“-fsanitize=memtag”选项来保护堆栈。
二、Trustonic如何在Kinibi 600中使用MTE？
通过Kinibi，我们希望为TEE本身的可信应用程序[TA]提供新的MTE功能。这个想法是为了让TA尽可能无痛地采用MTE。
当硬件支持MTE时，它会自动启用，用于TA的动态内存管理。这意味着用TEE_Malloc（）分配的缓冲区会被自动标记，并且每次调用TEE_Mallock（）都会返回一个带有不同标记的缓冲区。
因此，如果应用程序试图访问超出分配大小的缓冲区，CPU将检测到它并立即停止TA。MTE还将检测缓冲区在释放后何时被访问，或者何时被释放两次。
通过检测所有这些常见的错误，MTE展示了它的威力，TA将从中受益，而无需更改一行代码。堆的结构——或者元数据——总是受到一个特殊标记的保护。
因此，应用程序无法错误访问元数据。
该过程如下图所示：
当我们为Kinibi 600的动态分配启用MTE时，我们修复了TEE中的几个问题。
在这个项目中，我们不得不重写动态分配器[libheap]的大部分内容，使其与MTE兼容。我们利用这次开发的机会增加了单元测试的代码覆盖率，库中代码行的覆盖率达到了99.6%。
当我们开始这个项目时，我们没有任何可用的MTE硬件，因此我们决定使用Quick Emulator[QEMU]。可以通过“MTE=on”选项使用MTE启动QEMU。
MTE可以在正常世界（Linux和用户空间应用程序）和安全世界（TEE和TA）中独立启用和使用。当真正的硬件还不可用时，能够使用具有新硬件功能的QEMU是特别方便的。
以下代码片段显示了在QEMU中使用MTE进行动态分配的效果：
我们可以看到，可信应用程序被TEE杀死，因为它试图用相同的标签访问超出分配的缓冲区。
在这里，我们可以看到TA被TEE杀死，因为它试图访问先前已释放的缓冲区。
MTE为抵御攻击提供了良好的保护，同时提供了一种使代码更加健壮的有效方法。此外，TA还可以使用MTE来保护其堆栈。为此，必须使用适当的选项重新编译TA。总之，我们强烈建议开发人员使用MTE。
该功能不仅具有高度可扩展性，而且在整个项目中我们没有遇到任何性能问题。
三、什么是FF-A？
2017年，ARM发布了Armv8.4，其中最突出的功能是SEL2中的安全管理程序。此后，我们一直与Arm保持定期联系，讨论对TEE的影响。2020年，我们提出了如何利用TEE中Hypervisor的愿景。
除了硬件方面的变化，ARM还宣布了一款名为Hafnium的开源Hypervisor，旨在使用ARM公开讨论的标准化通信协议。
最终，Hafnium被称为FF-A，对它的支持随后被添加到Linux内核、Trusted Firmware A[TF-A]–EL3–和Kinibi中。我们普遍认为FF-A可以在体系结构的任何级别上工作，并且即使一些组件不存在，例如在历史系统中，也可以工作。
为了实现这一目标，ARM联系了生态系统中的主要参与者，包括Trustonic，并在几个月的时间里讨论了这些要求。我们与Arm的会议始于2018年，并持续每两个月举行一次。
四、FF-A如何在Kinibi 600中工作？
作为我们未来发展项目的一部分，我们在ARM架构团队固定虚拟平台[FVP]初步工作的基础上，于2020年启动了FF-A原型。
2021年，我们将原型移植到HiKey960板上，并重新设计了内存管理，以支持ARM的Total Compute v0[TOC]平台上的Hafnium Hypervisor。
当年年底，我们与两个芯片客户共享了第一个FF-A版本。
然后，在2022年，为使我们的客户能够验证最常见的TEE用例，如Keymaster、Trusted User Interfaces[TUI]（电话支付）和Widevine的数字版权管理[DDRM]系统， 我们集成了FF-A v.1.1的修改版本，还增加了DRM和TUI所需的应用程序编程接口[API]，如drApiMapFfaBuffer（）。
如今，2023年，我们已经在QEMU上建立了FF-A的原型，并为TF-A开源项目做出了贡献。
考虑使用FF-A的客户需要考虑几个重要方面：
-
在Linux内核或任何选择的操作系统[OS]中支持FF-A。Trustonic可以提供支持，帮助将FF-A集成到操作系统中。
-
Hypervisor是否支持FF-A？
-
应使用最新的TF-A固件在EL3中获得FF-A支持。
-
客户可以使用Hafnium或他们自己的Hypervisor来实现安全世界。Kinibi可以在有或没有FF-a的设置中用于各种配置。
如今，FF-A主要由谷歌在基于Android的设备推出。然而，我们也有其他合作伙伴对FF-A的执行持积极支持的态度。
值得注意的是，FF-A是通用的，可以在Armv9平台上使用——在安全世界中有或没有Hypervisor均可，也以在Armv4上使用。这平稳的升级路径将现有的板支持包[BSP]改为FF-a，无需将Hypervisor作为初始步骤，而是在第二步骤中将其添加进来。
关于FF-A，安全世界中的虚拟机被称为安全分区。安全世界中的虚拟机监控程序称为安全分区管理器。
在Armv9-A架构上，Hypervisor分为两部分：运行在SEL2中的SPM核心[SPMC]和运行在EL3中的SPM-调度器[SPMD]。
在Armv8体系结构上，SPMC和SPMD都在EL3中运行。Kinibi现在还支持具有FF-A的设备树格式，这是TF-A实现所要求的。
一些最大的科技公司正在研究FF-A，并将对其的支持作为其即将推出的产品的一项要求。
Trustonic非常适合通过使用Kinibi 600来帮助原始设备制造商和硅供应商实现这一目标，该产品标配FF-A支持。Kinibi 600可供硅供应商评估，也可通过与我们现有的一些硅合作伙伴实施的集成供原始设备制造商（OEM）评估。
五、总结
Armv9-A是Arm处理器发展的下一步。作为一家安全公司，我们对MTE感到特别兴奋。虽然它的主要作用是早期检测程序中的错误，但在实践中，这增加了额外的安全层，因为攻击者无法再利用这些错误。
MTE使攻击者的生活更加艰难，从而使我们客户的系统更加安全。