[参考译文] AM6548：在 TrustZone 安全状态下运行的 A53内核的 DMA/高速缓存一致性

尽管在 UDMA 操作完成后主机 A53内核缓存失效正在使接收缓冲区失效、但总体而言、PRU-ICSSG 接收路径似乎存在类似的一致性问题。  您能建议应该采取哪些其他步骤吗？  TI 是否有在 TrustZone 安全世界中将 PRU-ICSSG EMAC 接口与 A53结合使用的示例？

Derek Chu 说：

TI 是否有在 TrustZone 安全世界中将 PRU-ICSSG EMAC 接口与 A53结合使用的示例？

否。 我们确实提供了 AM65x DMA 缓存一致性和安全事务的示例。 整体而言、安全事务性能不是设计优先考虑的问题、而是逻辑安全性、即使它具有严重的副作用。

Derek Chu 说：

请说明这种"应该可以正常工作"(正如您似乎建议的那样)、或者如果不是需要更改什么硬件配置才能实现这一目的。  我查看了 AM65x TRM 第10.2.9.3节中的 NBSS 寄存器文档、但没有找到任何对安全/非安全的引用-我漏掉了什么？

应通过 NBSS 从发起方传输安全/非安全数据。 因此、只要 ICSSG 发起安全事务、它就应该通过。 但可能我不清楚、我认为我们没有任何可生成安全事务的 ICSSG 固件？ 正在使用什么来生成安全表单 ICSSG？

谢谢 Pekka

user4068379 说：

否。 我们确实提供了 AM65x DMA 缓存一致性和安全事务的示例。

我认为在安全世界中将 PRU-ICSSG 与 A53主机结合使用的示例(尽管您有更通用的 UDMA 的示例)是"否"；是这样吗？

user4068379 说：

所以只要 ICSSG 启动安全事务，它就应该通过。 但可能我不清楚、我认为我们没有任何可生成安全事务的 ICSSG 固件？ 使用什么来生成安全表单 ICSSG？

我使用标准 PRU-ICSSG EMAC 固件(v02.02.12.08)。  如果正确理解 这意味着、为了使 PRU-ICSSG UDMA 事务在安全世界中与 A53主机保持缓存一致、PRU EMAC 固件需要 以不同的方式启动事务(即以一种在一致性硬件看到的物理地址中设置安全位的方式)？   请、TI 能否提供该固件？

Derek Chu 说：

我认为对于在安全世界使用 PRU-ICSSG 与 A53主机的示例，您的意思是"否"(尽管您有这样的示例用于更一般的 uDMA)；是这样吗？

是的。 由 CPSW 或 ICSSG 以太网单独使用的 uDMA。 没有安全的 uDMA (至少我知道)。

Derek Chu 说：

我正在使用标准 PRU-ICSSG EMAC 固件(v02.02.12.08)。  如果正确理解 这意味着、为了使 PRU-ICSSG UDMA 事务在安全世界中与 A53主机保持缓存一致、PRU EMAC 固件需要 以不同的方式启动事务(即以一种在一致性硬件看到的物理地址中设置安全位的方式)？   TI 能否提供该固件？

ICSSG 以太网使用了 UDMA-P、因此您是正确的、需要设置安全性才能使事务显示为安全。 我很确定这还没有经过试用、没有顶级用例可以将 ICSSG 作为安全世界的一部分。

因此、AM65x 有几个超越系统级用例的未知情况或功能。 通常、A53的缓存一致性和来自 NBSS 的流量被标记为安全。 然后、ICSSG 标准以太网(使用 uDMA-P)需要生成安全事务。 我怀疑对此或约束会有一定的限制。 但让我们来检查一下：

1.您是否让 Flow ICSSG 以太网到非安全存储器使用缓存一致性？

2.是否有其他启动程序通过 NBSS 发送安全事务？

谢谢澄清、Pekka。  要回答您的问题、请执行以下操作：

user4068379 说：

1. 您是否让 Flow ICSSG 以太网到非安全存储器配合高速缓存一致性工作？

可以、只要我们的 PRU-ICSSG EMAC 驱动程序在安全环境中在 A53上运行、无需显式缓存管理操作来确保传输正确的数据、就可以。

在安全的世界中使用 A53时、如果使用相同的驱动器而未更改代码、首先我看到的是发送路径不能正常运行。  在将缓冲区交给发送 uDMA 通道之前添加显式缓存清空似乎解决了这一问题。  但是、接收路径仍然存在问题、并且在从接收 uDMA 通道接收到已完成的缓冲区后添加显式缓存无效不会解决这些问题。

user4068379 说：

2. 您是否有其他启动程序通过 NBSS 发送安全事务？

据我所知、PCIExpress 是唯一的一种情况。  我还没有尝试过。

Derek Chu 说：

在安全环境中使用 A53时，使用相同的驱动程序而没有更改代码，我首先看到传输路径无法正常运行。  在将缓冲区交给发送 uDMA 通道之前添加显式缓存清空似乎解决了这一问题。  但是、接收路径仍然存在问题、从接收 uDMA 通道接收完成的缓冲区后添加显式缓存无效不会解决这些问题[/报价]

如何将来自 uDMA-P 通道的来自 ICSSG 的流量设置为安全？

我们的 PCU-ICSSG EMAC 驱动器对 UDMA 的配置与安全世界中的 UDMA 的配置没有任何不同。  在之前的主题中、您说：

"我查看了 NB 寄存器和规格、看起来它会从发起方传递安全或非边带信息。"

如果 A53内核是启动器/当   A53内核是启动器时、我认为这是指与 DMA 缓冲器物理地址关联的安全/非安全指示器将由 NBSS 硬件根据 A53的当前 TrustZone 安全状态自动设置。

如果情况并非如此、您能否说明 A53上的软件如何明确配置 uDMA 通道以执行安全传输？

当 PRU-ICSSG EMAC 固件是 uDMA 启动器时、我假设固件需要配置 UDMA 通道以在正确的安全状态下执行传输。  A53上的软件是否可以指示 EMAC 固件需要哪种安全状态、如果需要、如何操作？

Derek Chu 说：

"我查看了 NB 寄存器和规格、看起来它会从发起方传递安全或非边带信息。"

如果 A53内核是启动器/当   A53内核是启动器时、我认为这是指与 DMA 缓冲器物理地址关联的安全/非安全指示器将由 NBSS 硬件根据 A53的当前 TrustZone 安全状态自动设置。

[/报价]

纵观 AM65x 规范的以太网路径：ICSSG -> PSIL -> UDMA-P -> NBSS -> MSMC ->内存。 UDMA-P 和 NBSS 直接通过来自引发器的安全总线信息、因此为了获得安全设置、必须从 ICSSG 固件一直到 PSIL 接口。 根据我可以告诉 ICSSG 无法在 PSIL 上生成安全事务的说法、 标准以太网固件当然不会。

Derek Chu 说：

当 PRU-ICSSG EMAC 固件是 uDMA 启动器时，我假定固件需要配置 uDMA 通道才能在正确的安全状态下执行传输。  A53上的软件是否可以指示 EMAC 固件需要哪种安全状态，如果需要，如何操作？

在 AM65x 中、安全属性似乎不是按通道(它位于较新的 AM64x、AM62x、...按流 ID)、而是从 PSIL 接口传递。 因此、发起方需要能够生成此类事务、而我看不到 ICSSG 能够生成此类事务(安全绑定到0)。 在启动器接口上、如果有 ISC、则会对其进行全局设置。

[/quote]

谢谢 Pekka。  如果我理解正确、就会说  安全世界中的 A53与 PRU-ICSSG DMA 之间的缓存一致性不受硬件支持。

user4068379 说：

在启动器接口上，如果有 ISC，则配置将全局设置安全。

但只有系统固件才能实现该功能、对吗？  (根据我的理解、 A53内核无法访问 iSC。)

对于 PCIe 端点和主存储器之间的事务、在安全世界中的一致性如何？

Derek Chu 说：

谢谢 Pekka。  如果我理解正确、就会说  安全世界中的 A53与 PRU-ICSSG DMA 之间的缓存一致性不受硬件支持。

Pekka VARiS 说：

在启动器接口上、如果有 ISC、则会对其进行全局设置。

但只有系统固件才能实现该功能、对吗？  (根据我的理解、 A53内核无法访问 iSC。)

[/报价]

是、但更一般的情况不仅限于安全事务的缓存一致性。 我认为 ICSSG 不能在 AM65x 上生成安全事务。

Derek Chu 说：

对于 PCIe 端点和主存储器之间的事务，在安全环境中的一致性如何？

我没有看到专用于 PCIe 的 ISC。 因此、来自 PCIe 的所有事务都将不安全。 在一般安全架构中、将 PCIe 视为安全(ISC 是全局设置、而不是基于区域)会产生重大影响、因为 EP 可以读取或写入任何安全存储器。  

很抱歉在这里围绕高速缓存一致性进行了盘旋、但我没有深入研究引发器能够在 AM65x 上生成安全事务的一个级别。

[/quote]

谢谢 Pekka、无需道歉。

所采用的电压点。  事实证明,这不应该是这个项目的一个关注,但很好地知道一般。

回顾一下,我应该特别问的关于 PRU-ICSSG EMAC 的问题是:在 TrustZone 安全世界中,它是否能被主机(A53)使用?  我想我明白您在上面概述的关于 PRU-ICSSG 硬件无法生成安全事务的内容、 但是、如果唯一的问题是缺少缓存一致性、我希望通过让基于主机的驱动程序 对 DMA 缓冲区进行显式缓存管理(刷新和失效)来使其正常工作。  到目前为止尚未证明情况：UDMA 传输完成(大概是从 MSMC SRAM 到主存储器)后、我仍然看到接收缓冲区中有哪些数据似乎是过时的。  我想知道是否有另一个限制我没有考虑、如果有、是否可以通过 A53上的软件来缓解该限制。  一如既往地欢迎您提出意见和建议。

ETA： 大声思考：交易 NBSS -> MSMC (非安全、如上所述)和 MSMC ->主存储器(安全)之间是否存在不匹配？ 如果 UDMA 从 A53启动器继承)、这会导致我看到该行为？

我将查看 AM65x 和后续 AM64x 规格、以找出两者之间的差异。 那么、几个关键事项：

- ICSSG 可以进行直接总线事务,也可以使用 DMA (在 AM65x 中连接 UDMA-P 的 PSIL 接口,在 AM64x 中连接 PktDMA )
- AM65x UDMA-P 通过安全/非安全从发起方(发起方是事务发起方/总线主控,而不是谁配置它)
- AM64x PktDMA 每个流都有一个安全/非安全的配置。 因此、在理论上、根据 ICSSG EMAC 使用的流程配置此器件可以确保安全。
- ICSSG 无法在 PSIL 上设置安全模式->这意味着在 AM65x 上 UDMA-P 将始终不安全。 NBSS 将其直接传递到 MSMC SRAM。
- ICSSG 在 AM64x 上的正常总线事务有16个区域,每个区域都有 ISC。 我在 AM65x 上完全看不到此 ISC。
A53 (或 R5)状态(如在安全或未配置 DMA 或 ICSSG 时)不会直接继承其正在配置的外设的访问权限。 通常、您希望对安全外设进行防火墙保护、以使非安全外设无法访问它。  

硬件中的高速缓存一致性是对软件管理的高速缓存一致性的纯粹性能优化。 因此、我只会在逻辑数据流可行时查看它。

回到逻辑数据流。 对于缓冲区和描述符、您在 A53的 MMU 页表中有一个标记为"安全"的存储器区域。 您拥有使用该地区的 ICSSG EMAC 吗？ 您是否配置了防火墙、以便只有安全的非 A53启动器才能访问它？ 在这种情况下、防火墙将捕获访问权限。 如果你没有防火墙区域,任何其他非安全启动器如 DMA, R5,..可以访问该存储器,所以在实践中它不再安全.

我的一般指导是让 A53软件反弹/memcpy()是你需要的安全世界的帧。 无论如何、通过以太网线、RGMII 接口、可以查看内容。

再次感谢。  简单地说、这里使用 TrustZone 安全机制的唯一原因是、AM65x 防火墙可以区分两个内核集群-没有针对 TrustZone 支持的原始系统级要求、 但 TI 指出、必须让防火墙配置按预期工作。  因此、实施对 TrustZone 的支持只是工作防火墙配置的先决条件、而不是本身的目的。  (也就是说，我不知道用 TrustZone 作为控制访问硬件资源的方法是否可以替代防火墙。)

目前、我所测试的系统中未配置任何硬件防火墙。  此外、我非常确信在安全世界中运行的操作系统的 MMU 配置并未在任何 MMU 表或块描述符中设置 SECURE 位、因此 所有映射的存储器都将被视为不安全的。  我可以使用这种方法进行实验。

感谢您尝试找出使用安全/非安全模式之外的其他方法。 安全世界是一种不优先考虑性能而是安全的体系结构。 因此、一个群集运行安全、而另一个群集似乎不是很粗略。

-我的第一个想法是使用 MMU 和页表条目。 例如，一个群集上运行的进程和另一个群集上运行的进程应该不同。 这还不够吗？ 或者您需要明确使用防火墙？

我们将跨核心集群边界运行 AMP OS 配置；一个核心集群运行的是 OS 的安全认证版本、另一个被视为"不安全"。  主要 要求是防止非安全 OS 域中的软件(以及扩展的支持 DMA 的硬件)访问为在安全 OS 域中使用而保留的资源。  使用硬件防火墙似乎符合这一要求、但正如我之前提到的、这增加了在不同 TrustZone 环境中运行核心群集的复杂性。  如果有更好的方法可以实现符合功能安全目标的主要要求、那么我们应该与系统架构师讨论这一点。

我想我们已经找到了一个可行的方法、在有关此主题的调用中将某些功能与其他功能隔离、结束此线程。