12. Arm 动态 Trustzone 技术介绍_arm gpt 粒度保护

源自 李平；

十多年来，TrustZone 一直在成功保护基于 Arm 的设备上的媒体管道。在此期间，这些设备的要求随着比特率、分辨率、帧速率、图像质量和用户界面的创新而显着增长。所有这些都在推动最初的设计约束。

与此同时，近年来，许多消费类设备都经历了重大变革。他们正在从专用于单一服务的封闭设备转向兼容多种服务的开放设备。例如，电视不再仅用于观看广播电视频道。可安装应用程序现在提供多种流媒体服务、浏览器、游戏、视频通话等。

满足这些用例会增加计算工作负载的复杂性和系统安全要求。在安全性方面，我们看到多个数字版权管理 (DRM) 方案同时处于活动状态，并且它们之间存在健康的不信任，因为它们处理来自具有不同安全要求级别的不同来源的受保护内容。这种对额外灵活性的需求正在推动软件管理媒体管道的设计。

同时，内容提供商正在通过提高图像质量来提高性能要求。这增加了流水线中的处理步骤数量，并大大增加了设备上的内存消耗。对有效内存使用的需求推动了一种机制的设计，用于动态分配受保护的内存。

动态信任区

这就是 Arm 引入动态 TrustZone 的原因，这是一种创新的新设计模式，它是 TrustZone 系统进化路径的下一步。该技术使用领域管理扩展 (RME) 来提供一种架构机制，以便在运行时在非安全和安全地址空间之间分配内存页面。

当应用于受保护的媒体管道时，动态 TrustZone 支持从今天的固定功能视频管道迁移到未来的软件配置动态媒体管道。具有动态 TrustZone 和安全虚拟化的系统将支持软件配置的管道、多个不信任 DRM、可选的机器学习 (ML) 加速器和动态资源分配。

然而，这些未来媒体管道的实际设计和实施需要整个生态系统的支持和参与。这超越了硬件，更广泛的生态系统的参与对于支持这些苛刻的新用户体验所需的所有软件组件和服务的接受和成功开发至关重要。

典型的安全媒体路径

在深入研究动态 TrustZone 之前，我们需要首先反思当今常见的媒体管道。Arm 系统中实施的受保护媒体管道倾向于遵循 TrustZone 媒体保护 (TZMP) 定义的模式，如下图的简化形式所示：

这些系统有一些共同的特点和限制：

由特定于设备的软件或在 SoC 设计时定义的固定数据流和一组处理步骤。每个处理元件通常被限制为读取和写入预先确定的受保护内存缓冲区，并且不允许任意添加和删除设备。将完全可编程的 GPU 和 ML 引擎引入流水线可能从不可能到具有挑战性。

受保护内容的受保护内存缓冲区的物理地址空间是连续的和预先分配的，或者是分段的并由受信任的管理程序管理。由于视频播放是许多设备的主要用例，并且绝不能丢帧，因此所使用的内存不能与其他系统进程共享。随着分辨率和帧速率的增加，内存需求压力也随之增加，从而推高了整体系统成本。

在同时处理多个内容流的情况下，需要考虑它们之间的隔离。由于不同的安全要求，可能无法同时使用不同的 DRM 方案。

为了克服这些限制，我们确定未来受保护的媒体系统需要能够：

使用分段的 4Kbyte 页面动态分配和管理受保护的内存缓冲区。

在多个管道和所有其他软件之间提供强大且安全的隔离。

将设备和软件功能任意分配给管道。

允许运行时主机软件按需创建和配置管道。

新的 Arm 安全性和架构特性

在过去十年中，Arm 一直在对 TrustZone 进行定期增强，以满足不断变化的安全要求。在宣布 Armv9 架构 (Armv9-A) 之前，我们通过添加安全虚拟化增强了 TrustZone 系统。在 Armv9-A 中，我们引入了领域管理扩展 (RME) 作为 Arm 机密计算架构的一部分。

随着这些新安全功能的添加，现在有一套完整的系统设计人员可以实现未来的受保护媒体管道。让我们更深入地研究这些增强的功能。

安全虚拟化

首先，让我们看看安全虚拟化。这是为了进一步划分安全世界以允许存在多个受信任的操作系统 (TOS)、隔离安全固件以及另外提供对非安全内存的 TOS 访问的限制。

安全虚拟化通过在 TrustZone 环境中创建安全虚拟机来工作。安全世界中的这些虚拟机实例，通常称为“安全分区”，使用第 2 阶段内存转换和保护相互隔离。当然，由于处于安全世界中，它们与非安全世界完全隔离。安全虚拟化通过以下架构特性实现：

Secure-EL2 是在 Armv8.5 架构中引入的，它是为执行隔离管理程序而创建的 CPU 异常级别，称为“安全分区管理器”（SPM）。SPM 的作用是创建和管理多个不信任安全分区。S-EL2 使用第二阶段内存转换和保护来强制分区之间的隔离。

SMMUv3.2 扩展了 Arm 系统 MMU 架构，以支持安全阶段 2 转换和对系统中安全设备的保护。隔离管理程序可以将系统设备分配到安全分区的内存空间中。

GICv3.1 通用中断控制器包括对 S-EL2 的支持。来自安全系统设备的虚拟中断可以分配给安全分区。

我们应该注意到，在实践中，将安全设备分配给安全分区需要的不仅仅是内存与 SMMU 的映射以及与 GIC 的中断。每个设备都必须在其运行状态方面表现良好，并支持标准管理界面，以便在系统内对其进行安全和正确的管理。

领域管理扩展 (RME)

作为 Arm 机密计算架构的一部分，Armv9-A 中的 RME 使内存页面能够从非安全世界动态转换到安全世界并再次返回。这就是将“动态”放入动态 TrustZone 的原因。

RME 的一个组件称为“颗粒保护检查”（GPC），提供了在非安全和安全世界之间动态分配内存的机制。颗粒保护表 (GPT) 记录了 DRAM 的每个 4K 字节页面的世界分配。此表由 EL3 固件拥有和更新。在运行时，每个内存访问都由 GPC 对照 GPT 进行验证，确保 Non-secure 状态只能访问 Non-secure 内存，Secure 状态只能访问 Secure 和 Non-secure 内存。此检查是对 MMU 已经进行的 stage-1 和 stage-2 翻译和权限检查的补充。

然后，在 RME 之上构建，机密计算架构提供了以下附加功能，可以增强动态 TrustZone 解决方案：

EL3 监视器的固件分区和隔离，用于提供更强大的信任根 (RoT) 和证明服务。

通过内存保护引擎加密安全分配的 DRAM 中的所有数据。

具有动态 TrustZone 的媒体管道

之前概述的架构特性允许系统设计人员迁移到具有多个软件定义的受保护媒体管道的动态 TrustZone 技术解决方案。它看起来像这样：

这里发生了什么？

安全虚拟化

如绿色框所示，安全虚拟化用于为每个管道创建受保护的内存空间。设备分配将系统设备（蓝盒）带入管道，而内存缓冲区（黑盒）通过 GPT 机制分配给安全世界。所有解密的媒体内容在使用期间都保留在安全世界中。

不安全的世界

这包含媒体播放器和应用程序的用户界面。该软件负责为每个媒体管道按需构建清单，并在它们过渡到安全世界之前为其分配资源，例如内存和系统设备。

安全媒体管道 1

此示例中的管道 1 正在处理受保护的音频。处理步骤可以由硬件设备或软件编解码器执行。一个例子是高级环绕声流，它使用专有编解码器来处理基于对象的高价值音频内容。

安全媒体管道 2

Pipeline 2 可能是一部 8K 优质内容电影，具有严格的 DRM 要求和稳健性规则，可确保视频和音频流与系统上的任何其他代理隔离。由于 8K 分辨率视频对其缓冲区的内存要求非常高，这可能是电视等设备的主要用例。非安全主机操作系统可能会积极地从其他应用程序中回收内存，以便在初始化播放时可以动态分配这些受保护的缓冲区。

解密步骤将使用专用的加密加速器，并使用专用的视频引擎进行解码。举例来说，图片质量步骤可以由分配给该管道的高性能 ML 引擎执行。

安全媒体管道 3

流水线 3 可以是画中画新闻报道，可能具有与流水线 2 不同的 DRM 系统。当流启用时，可以为该流水线的受保护缓冲区动态分配内存，而不会中断流水线 2。

安全媒体输出

最后，将完全渲染的受保护内容输出到显示面板或安全的 HDMI 链路。

生态系统协作

Dynamic TrustZone 是提供多租户安全媒体管道的绝佳工具。一个完全不受操作系统、管理程序和正常世界中任何可安装应用程序影响的管道。该解决方案还允许在正常环境中部署标准虚拟机管理程序，而无需更改它们以支持 DRM。

但是，设计多租户安全媒体管道需要整个生态系统的支持和参与。这不仅限于硬件，因为多租户安全媒体管道可能会带来策略挑战，尤其是当两个不同的流视频提供商对如何执行策略有不同的要求时。因此，受保护媒体管道的灵活性为细粒度的信令和安全策略检查提供了机会，例如水印、元数据传输和内容识别等。

可以通过内容交付和安全协会(CDSA)、芯片供应商、原始设备制造商、OTT 服务提供商、内容创建者等行业组织来实现与生态系统的互动。他们都为对话带来了独特的视角和专业知识，通过这种协作努力，为全球数百万用户带来了更丰富的媒体体验。

在 Arm，我们希望与我们强大的生态系统合作，以解决我们共同构建的设备上的许多安全挑战。使用动态 TrustZone 的工作是可以在 Arm 生态系统内进行的安全协作的一个很好的例子。