TrustZone 系统上的安全 DMA 和非安全 CPU 之间是否会发生一致性问题
Can coherency issue happen between secure DMA and non-secure CPU on TrustZone system
我遇到了一些我认为与 DMA 和 CPU 之间的一致性有关的问题。这是简化的用例。
Cortex A5 CPU在非安全状态下写入非安全内存。启用MMU，内存属性为normal、shareable、cacheable。
因此，根据以下参考资料，数据可能位于所谓的非安全缓存中：
[1] "Data Cache Tag data format" 在 DDI0434B_cortex_a5_mpcore_r0p1_trm
[2] 来自 Secure mode can access secure / non secure memory how?
中无艺术噪音的回答
[3] http://atmel.force.com/support/servlet/fileField?id=0BEG000000002Ur
DMA 向该内存区域发出安全一致读取。 DMA 连接到 ACP。
SCU 只会尝试检查标记为安全的缓存。所以根据DDI0434B_cortex_a5_mpcore_r0p1_trm.
DMA 可能会获取过时数据。
如果我的描述是正确的，这是我的第二个问题。
哪个动作可以解决这个问题？
1) 在 DMA 读取之前明确清除缓存
2) 将内存的属性改为普通、可共享、不可缓存。
TRM 还说有一个写入缓冲区，用于在 "Bus Interface Unit and SCU interface" 中的 SCU 接口上写出缓存逐出或不可缓存的写入突发数据之前保存这些数据。但是找不到有关写入缓冲区的更多信息。我可以假设写缓冲区有一些魔法来确保一致性吗？如果有人能解释一下魔法，我将不胜感激。
考虑更多的组合，我自己得到这个table
CPU state | Memory | DMA access | Result
-----------+------------+------------+-----------+
non-secure | non-secure | non-secure | OK
non-secure | non-secure | secure | NG
non-secure | secure | - | NA
secure | non-secure | non-secure | OK
secure | non-secure | secure | NG (Same reason as the second case)
secure | secure | non-secure | NA
secure | secure | secure | OK
第一列显示CPU在哪种状态下写入内存。
第二列显示内存是否安全。这里 "secure" 表示如果 AxPROT[1] 为高，AXI 将拒绝访问。内存属性正常，可共享，可缓存。
第三列显示了什么样的存取DMA问题。访问一致。
第四列告诉会发生什么。
NG 意味着 DMA 可能得到过时的数据。
NA表示无法访问
OK 表示 DMA 与 CPU 一致。
对吗？
这部分是我根据Notlikethat的回答加上的。这可能是实践中的噩梦。但是我想知道理论上会发生什么。
- 假设物理地址0x10映射到两个虚拟地址，NS:0x110和S:0x210。
- CPU在安全状态下将值0x110写入NS:0x110，然后将值0x210写入S:0x210.
所以两者可能同时在 L1 缓存中，对吗？
- 然后 DMA1 对 PA 0x10 进行安全读取并可能获得 0x210。 DMA2 对 PA 0x10 进行非安全读取并可能获得 0x110。
- 之后是不可预知的table最后哪个会进入主存
请确认或纠正我的理解。非常感谢。
在架构上，您无法做到 "secure accesses to non-secure memory"。安全和非安全的物理地址空间是独立的（许多支持 TrustZone 的系统有一些东西出现在不同的地址以进行安全访问和非安全访问）。但在实践中，很多外围设备（包括内存控制器）都无法识别 TrustZone，因此在大多数系统上都位于 TZASC 之后，此时安全和非安全地址空间在很大程度上重叠。
在 CPU 上，安全软件通过设置了 NS 位的页面 table 条目或从设置了 SCR.NS 的监控模式访问非安全内存；在这两种情况下，生成的总线访问都设置了 AxPROT[1]，即它是非安全访问。如果您希望外围设备正确访问非安全内存，您需要让它以类似的方式发出非安全访问。
否则，您遇到的是更普遍的物理别名问题，除非绝对必要，否则通常不推荐使用 - 更传统的例子是 DRAM 的系统在相当高的物理地址（例如 0x80000000，甚至在支持 LPAE 的系统上超过 32 位），其中一部分被别名向下（例如，在 0x0 用于引导向量）以供在设置 MMU 之前使用。即使是物理标记的缓存也不知道 0x0 和 0x80000000 实际上最终位于互连另一端的同一位置，因此如果您同时使用两者，您确实会遇到超出范围的一致性噩梦体系结构，并且只能通过显式缓存维护进行管理。
以同样的方式，将安全状态作为物理地址标签的一部分的 TrustZone 感知缓存并不知道 S:0x80000000 和 NS:0x80000000 可能最终会出现在在您的特定系统上的相同位置（一般来说，它们很可能不一致），因此，除非手动管理，否则这两个地址是不一致的 - 写入一个别名的数据必须从缓存中清除到 TZASC 之外的某个点（即通常一直到 DRAM），然后才能从另一个可见。请注意，如果您的 Cortex-A5 系统有一个像 PL310 这样的外部 L2 缓存，这意味着通过 VA 清理 CPU 缓存到 PoC，然后通过适当的 secure/non-secure 访问通过 PA 清理 L2，这可能所有这些都必须由安全世界单独完成，以避免同步问题。从理论上讲，让所有内容都进行不可缓存的访问将通过强制所有数据通过 DRAM 进行往返来解决一致性问题，尽管某些外部缓存配置仍然会阻碍这一点并非不可能。让 DMA 控制器在适当的地方直接发出非安全访问要好得多，这样你实际上可以 从缓存中受益 而不是对抗它们。
我遇到了一些我认为与 DMA 和 CPU 之间的一致性有关的问题。这是简化的用例。
Cortex A5 CPU在非安全状态下写入非安全内存。启用MMU，内存属性为normal、shareable、cacheable。 因此，根据以下参考资料，数据可能位于所谓的非安全缓存中：
[1] "Data Cache Tag data format" 在 DDI0434B_cortex_a5_mpcore_r0p1_trm
[2] 来自 Secure mode can access secure / non secure memory how?
中无艺术噪音的回答[3] http://atmel.force.com/support/servlet/fileField?id=0BEG000000002Ur
中的第 6 页
DMA 向该内存区域发出安全一致读取。 DMA 连接到 ACP。
SCU 只会尝试检查标记为安全的缓存。所以根据DDI0434B_cortex_a5_mpcore_r0p1_trm.
中的"ACP requests"从主存返回数据
DMA 可能会获取过时数据。
如果我的描述是正确的，这是我的第二个问题。 哪个动作可以解决这个问题？
1) 在 DMA 读取之前明确清除缓存
2) 将内存的属性改为普通、可共享、不可缓存。
TRM 还说有一个写入缓冲区，用于在 "Bus Interface Unit and SCU interface" 中的 SCU 接口上写出缓存逐出或不可缓存的写入突发数据之前保存这些数据。但是找不到有关写入缓冲区的更多信息。我可以假设写缓冲区有一些魔法来确保一致性吗？如果有人能解释一下魔法，我将不胜感激。
考虑更多的组合，我自己得到这个table
CPU state | Memory | DMA access | Result
-----------+------------+------------+-----------+
non-secure | non-secure | non-secure | OK
non-secure | non-secure | secure | NG
non-secure | secure | - | NA
secure | non-secure | non-secure | OK
secure | non-secure | secure | NG (Same reason as the second case)
secure | secure | non-secure | NA
secure | secure | secure | OK
第一列显示CPU在哪种状态下写入内存。
第二列显示内存是否安全。这里 "secure" 表示如果 AxPROT[1] 为高，AXI 将拒绝访问。内存属性正常，可共享，可缓存。
第三列显示了什么样的存取DMA问题。访问一致。
第四列告诉会发生什么。
NG 意味着 DMA 可能得到过时的数据。
NA表示无法访问
OK 表示 DMA 与 CPU 一致。
对吗？
这部分是我根据Notlikethat的回答加上的。这可能是实践中的噩梦。但是我想知道理论上会发生什么。
- 假设物理地址0x10映射到两个虚拟地址，NS:0x110和S:0x210。
- CPU在安全状态下将值0x110写入NS:0x110，然后将值0x210写入S:0x210.
所以两者可能同时在 L1 缓存中，对吗？ - 然后 DMA1 对 PA 0x10 进行安全读取并可能获得 0x210。 DMA2 对 PA 0x10 进行非安全读取并可能获得 0x110。
- 之后是不可预知的table最后哪个会进入主存
请确认或纠正我的理解。非常感谢。
在架构上，您无法做到 "secure accesses to non-secure memory"。安全和非安全的物理地址空间是独立的（许多支持 TrustZone 的系统有一些东西出现在不同的地址以进行安全访问和非安全访问）。但在实践中，很多外围设备（包括内存控制器）都无法识别 TrustZone，因此在大多数系统上都位于 TZASC 之后，此时安全和非安全地址空间在很大程度上重叠。
在 CPU 上，安全软件通过设置了 NS 位的页面 table 条目或从设置了 SCR.NS 的监控模式访问非安全内存；在这两种情况下，生成的总线访问都设置了 AxPROT[1]，即它是非安全访问。如果您希望外围设备正确访问非安全内存，您需要让它以类似的方式发出非安全访问。
否则，您遇到的是更普遍的物理别名问题，除非绝对必要，否则通常不推荐使用 - 更传统的例子是 DRAM 的系统在相当高的物理地址（例如 0x80000000，甚至在支持 LPAE 的系统上超过 32 位），其中一部分被别名向下（例如，在 0x0 用于引导向量）以供在设置 MMU 之前使用。即使是物理标记的缓存也不知道 0x0 和 0x80000000 实际上最终位于互连另一端的同一位置，因此如果您同时使用两者，您确实会遇到超出范围的一致性噩梦体系结构，并且只能通过显式缓存维护进行管理。
以同样的方式，将安全状态作为物理地址标签的一部分的 TrustZone 感知缓存并不知道 S:0x80000000 和 NS:0x80000000 可能最终会出现在在您的特定系统上的相同位置（一般来说，它们很可能不一致），因此，除非手动管理，否则这两个地址是不一致的 - 写入一个别名的数据必须从缓存中清除到 TZASC 之外的某个点（即通常一直到 DRAM），然后才能从另一个可见。请注意，如果您的 Cortex-A5 系统有一个像 PL310 这样的外部 L2 缓存，这意味着通过 VA 清理 CPU 缓存到 PoC，然后通过适当的 secure/non-secure 访问通过 PA 清理 L2，这可能所有这些都必须由安全世界单独完成，以避免同步问题。从理论上讲，让所有内容都进行不可缓存的访问将通过强制所有数据通过 DRAM 进行往返来解决一致性问题，尽管某些外部缓存配置仍然会阻碍这一点并非不可能。让 DMA 控制器在适当的地方直接发出非安全访问要好得多，这样你实际上可以 从缓存中受益 而不是对抗它们。