说明:
在默认情况下,本文讲述的都是ARMV8-aarch64架构
相关链接:
ARM trustzone学习和总结-一篇就够了
在安全架构的设计时,我们在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将会挡住你。
综上所述:安全就是安全,不要再瞎想漏洞了。
作者:代码改变世界ctw
文章来源:https://blog.csdn.net/weixin_42135087/article/details/122555854?spm=1001.2014.3001.5502
推荐阅读
更多物联网安全,PSA等技术干货请关注平台安全架构(PSA)专栏。欢迎添加极术小姐姐微信(id:aijishu20)加入PSA技术交流群,请备注研究方向。