快速鏈接:
.
👉👉👉 個人博客筆記導讀目錄(全部) 👈👈👈


說明：
在默認情況下，本文講述的都是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將會擋住你。

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

總結

以上是生活随笔為你收集整理的思考：通过MMU/TLB/Cache对安全内存攻击的可能性的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。