背景
十多年来，TrustZone 一直在基于 Arm 的设备上成功保护媒体 pipelines 。在此期间，这些设备的要求随着比特率、分辨率、帧率、图像质量和用户界面创新而显着增长。所有这些都在突破最初的设计限制。
与此同时，近年来，许多消费类设备都经历了重大变革。他们正在从专用于单一服务的封闭设备转向兼容多种服务的开放设备。例如，电视不再仅用于观看广播电视频道。可安装的应用程序现在提供多种流媒体服务、浏览器、游戏、视频通话等。
满足这些用例会增加计算工作负载的复杂性和系统安全要求。在安全方面，我们看到多个数字版权管理 (DRM) 方案同时处于活动状态，并且它们之间存在不信任，因为它们处理来自具有不同安全要求级别的不同来源的受保护内容。这种对额外灵活性的需求推动了软件管理媒体 pipelines 的设计。
同时，内容提供商正在通过提高图像质量来提高性能要求。这增加了 pipelines 的处理步骤数量，并大大增加了设备上的内存消耗。 对高效内存使用的需求正在推动设计用于动态分配受保护内存的机制。
动态 Trustzone
这就是 Arm 推出动态 TrustZone 的原因，这是一种创新的新设计模式，它是 TrustZone 系统演进道路上的下一步。该技术使用 Realm Management Extension (RME) 来提供一种架构机制，以在运行时在非安全和安全地址空间之间分配内存页面。
当应用于受保护的媒体 pipelines 时，动态 TrustZone 支持从今天的固定功能视频管道迁移到未来软件配置的动态媒体 pipelines。将动态 TrustZone 与安全虚拟化相结合的系统将支持软件配置的 pipelines、多个不信任 DRM、可选的机器学习 (ML) 加速器和动态资源分配。
然而，这些未来媒体管道的实际设计和实施需要整个生态系统的支持和参与。这超越了硬件，更广泛的生态系统的参与对于支持这些苛刻的新用户体验所需的所有软件组件和服务的接受和成功开发至关重要。
典型的安全媒体示例
在深入研究动态 TrustZone 之前，我们需要首先会议当今常见的媒体 pipelines。在 Arm 系统中实施的受保护媒体 pipelines 往往遵循 TrustZone 媒体保护 (TZMP) 定义的模式，如下图所示：
这些系统有一些共同的特点和局限性：
- 固定的数据流和一组处理步骤，由特定于设备的软件或在 SoC 设计时定义。每个处理元件通常被限制为读取和写入预先确定的受保护内存缓冲区，并且不允许任意添加和删除设备。将完全可编程的 GPU 和 ML 引擎引入流水线可能从不可能到具有挑战性。
- 受保护内容的受保护内存缓冲区的物理地址空间是连续的和预先分配的，或者是由受信任的管理程序分段和管理的。由于视频播放是许多设备的主要用例并且绝不能丢帧，因此不能与其他系统进程共享所使用的内存。随着分辨率和帧速率的提高，对内存要求的压力也随之增加，从而推高了整体系统成本。
- 在要同时处理多个内容流的情况下，需要考虑它们之间的隔离。由于不同的安全要求，可能无法同时使用不同的 DRM 方案。
为了克服这些限制，我们确定未来受保护的媒体系统需要能够：
- 使用碎片化的 4KB 页面动态分配和管理受保护的内存缓冲区。
- 在多个管道和所有其他软件之间提供强大且安全的隔离。
- 将设备和软件功能任意分配给 pipelines 。
- 允许运行时主机软件按需创建和配置 pipelines 。
新的 Arm 安全和架构功能
在过去的十年中，Arm 一直在对 TrustZone 进行定期增强，以满足不断变化的安全要求。在宣布 Armv9 架构 (Armv9-A) 之前，我们通过添加安全虚拟化增强了 TrustZone 系统。在 Armv9-A 中，引入了 Realm Management Extension (RME) 作为 Arm 机密计算架构的一部分。
通过添加这些新的安全功能，现在有一个完整的集合，使系统设计人员能够实现未来受保护的媒体管道。让我们更深入地研究这些增强功能。
Secure virtualization
首先，让我们看看安全虚拟化。引入此功能是为了进一步划分安全世界，以允许存在多个可信操作系统 (TOS)，隔离安全固件，此外还提供对 TOS 访问非安全内存的限制。
安全虚拟化通过在 TrustZone 环境中创建安全虚拟机来实现。安全世界中的这些虚拟机实例，通常称为 “安全分区”，使用第 2 阶段内存转换和保护相互隔离。当然，由于处于安全世界中，它们与非安全世界完全隔离。安全虚拟化是通过以下架构特性实现的：
- Secure-EL2 是在 Armv8.4 架构中引入的，它是为执行隔离管理程序而创建的 CPU 异常级别，称为 “安全分区管理器”（SPM）。SPM 的作用是创建和管理多个 不信任安全分区 S-EL2 使用第 2 阶段内存转换和保护来强制分区之间的隔离。
- SMMUv3.2 扩展了 Arm System MMU 架构，以支持系统中安全设备的安全第 2 阶段转换和保护。隔离管理程序可以将系统设备分配到安全分区的内存空间中。
- GICv3.1 通用中断控制器包括对 S-EL2 的支持。来自安全系统设备的虚拟中断可以分配给安全分区。
我们应该注意到，在实践中，将安全设备分配给安全分区需要的不仅仅是内存与 SMMU 的映射以及 GIC 的中断。每个设备都必须在其操作状态方面表现良好，并支持标准管理界面，以便可以在系统内安全、正确地对其进行管理。
Realm Management Extension (RME)
作为 Arm 机密计算架构的一部分，Armv9-A 中的 RME 使内存页面能够从非安全世界动态转换到安全世界，然后再返回。这就是将 “动态” 放入动态 TrustZone 的原因。
RME 的一个称为 “Granule Protection Check” (GPC) 的组件提供了在非安全和安全世界之间动态分配内存的机制。Granule Protection table (GPT) 记录了 DRAM 每 4K 字节页面的世界分配。该表由 EL3 固件拥有和更新。在运行时，每次内存访问都由 GPC 针对 GPT 进行验证，确保 Non-secure 状态只能访问 Non-secure 内存，而 Secure 状态只能访问 Secure 和 Non-secure 内存。此检查是对 MMU 已经进行的 stage-1 和 stage-2 转换和权限检查的补充。
然后，基于 RME 构建的机密计算架构提供以下附加功能，可以增强动态 TrustZone 解决方案：
- EL3 monitor 的固件分区和隔离，用于提供更强大的信任根 (RoT) 和证明服务。
- 通过内存保护引擎对安全分配的 DRAM 中的所有数据进行加密。
Media Pipelines with Dynamic TrustZone
先前概述的架构特性允许系统设计人员迁移到具有多个软件定义的受保护媒体 pipelines 的动态 TrustZone 技术解决方案。它看起来像这样：
(1)、Secure virtualization
如绿框所示，安全虚拟化用于为每个 pipelines 创建受保护的内存空间。设备分配将系统设备（蓝色）带入管道，内存缓冲区（黑色）通过 GPT 机制分配给安全世界。在使用过程中，所有解密的媒体内容都保留在安全世界中。
(2)、Non-secure world
这包含媒体播放器和应用程序的用户界面。该软件负责按需为每个媒体 pipelines 构建清单，并在过渡到安全世界之前为其分配资源，例如内存和系统设备。
(3)、Secure Media Pipeline 1
本例中的 Pipeline 1 正在处理受保护的音频。处理步骤可由硬件设备或软件编解码器执行。一个例子是高级环绕声流，它使用专有编解码器来处理高价值的基于对象的音频内容。
(4)、Secure Media Pipeline 2
Pipeline 2 可以是 8K 优质内容电影，具有严格的 DRM 要求和稳健性规则，可确保视频和音频流与系统上的任何其他代理隔离。由于 8K 分辨率视频对其缓冲区的内存要求非常高，这可能是电视等设备的主要用例。非安全主机操作系统可能会主动从其他应用程序回收内存，以便在初始化播放时可以动态分配这些受保护的缓冲区。
解密步骤将使用专用加密加速器，解码专用视频引擎。例如，图片质量步骤可以由分配给该流水线的高性能 ML 引擎执行。
(5)、Secure Media Pipeline 3
Pipeline 3 可能是画中画新闻报道，可能具有与 Pipeline 2 不同的 DRM 系统。当启用流时，可以为该管道的受保护缓冲区动态分配内存，而不会中断 Pipeline 2。
(6)、Secure Media Output
最后，完全呈现的受保护内容被输出到显示面板或安全的 HDMI Link。
生态系统协作
动态 TrustZone 是提供多租户安全媒体 pipeline 的绝佳工具。完全不受操作系统、虚拟机管理程序和正常世界中任何可安装应用程序影响的 pipeline 。该解决方案还允许在正常环境中部署标准管理程序，而无需更改它们以支持 DRM。
但是，设计多租户安全媒体 pipeline 需要整个生态系统的支持和参与。这超出了硬件本身，因为多租户安全媒体管道可能会带来策略挑战，尤其是当两个不同的流媒体视频提供商对如何执行策略有不同的要求时。因此，受保护媒体管道的灵活性为细粒度信令和安全策略检查提供了机会，例如水印、元数据传输和内容识别，仅举几例。
可以通过 Content Delivery and Security Association (CDSA)、芯片供应商、OEM、OTT 服务提供商、内容创建者等行业组织来实现与生态系统的互动。他们都为对话带来了独特的观点和专业知识，通过这种协作努力为全球数百万用户带来了更丰富的媒体体验。
在 Arm，我们希望与我们伟大的生态系统合作，以解决我们共同构建的设备上的许多安全挑战。使用动态 TrustZone 的工作是可以在 Arm 生态系统内进行的安全合作的一个很好的例子。
作者：baron
文章来源：Arm精选
推荐阅读
欢迎关注ARM精选专栏， 欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
