思考：通过MMU/TLB/Cache对安全内存攻击的可能性

快速链接: . 【购买须知】:

说明： 在默认情况下，本文讲述的都是ARMV8-aarch64架构 相关链接:

在安全架构的设计时，我们在Core和DDR之间增加了一个TZC做为memory filter，数据流为:Core ---> TZC---->DDR, 这种架构下，core以非安全身份发起的对安全内存的读写，将会被TZC挡住。

但是这都是在理想的情况下，事实上Core发起对内存的读写，未必经过TZC未必到DDR，有可能到cache阶段就完成了，即数据流变成了Core ---> MMU(TLB+Addtress Translation)---->Cache，那么这种情况下，没有TZC的事了，你也许会说MMU/Cache中都有NS比特，但是你真的理解这里NS比特的用法吗？ 如果core以非安全身份对安全内存发起的读写时，我强制将MMU页表中的安全属性标记位强制改成NS=0，会如何呢？

事实上我们只要理清原理、理清数据流 ，就不会问上面那么S13的问题了。 下面来开始剖析:

假设一个安全core 读取了一个安全物理内存0x2000_0000数据(虚拟地址可能是0x_xxxx_xxxx)，那么将产生一下行为：

在读写之前，势必做好了MMU map，如物理地址0x2000_0000 MAP成了0x_xxxx_xxxx地址, 此时Page Descriptor中的atrribute中的NS=0 TLB缓存该翻译，即TLB的entry中包含: 0x2000_0000、0x_xxxx_xxxx、NS=0 安全内存0x2000_0000数据将会被缓存到cache中，entry中的TAG包含0x2000_0000、NS=0

同时，我有一个非安全core 发起读写虚拟地址0x_yyyy_yyyy，我自行修改该页表，让0x_yyyy_yyyy强制映射到安全物理内存0x2000_0000，此时有两种配置: (1)、0x_yyyy_yyyy—0x2000_0000, NS=0 (2)、0x_yyyy_yyyy—0x2000_0000, NS=1 我们分别看下这两种配置，是否能读到安全内存： 针对(1)，非安全的core发起访问，发现TLB中的条目是0x_yyyy_yyyy—0x2000_0000, NS=0,自然不会被命中，然后使用Address Translation转换，MMU发现非安全的Core要来访问安全属性NS=0 将会被直接拒绝掉。 针对(2)，非安全的core发起访问，由于NS=1，TLB可能会被命中，即能翻译出0x2000_0000物理地址来，即使没有被命中，在经过Address Translation转换，由于NS=1，此时也是可以正确转换出正确的0x2000_0000物理地址。 然后接着会去cache中查询这个地址，但是此时cache的entry中的NS=0，所以cache不会被命中，接下来就要走TZC流程了，很显然，你一个非安全的core想访问安全的内存，TZC将会挡住你。

综上所述：安全就是安全，不要再瞎想漏洞了。