??個人主頁: Aileen_0v0
??熱門專欄: 華為鴻蒙系統(tǒng)學(xué)習(xí)|計算機(jī)網(wǎng)絡(luò)|數(shù)據(jù)結(jié)構(gòu)與算法|MySQL|
???個人格言:“沒有羅馬,那就自己創(chuàng)造羅馬~”

本文轉(zhuǎn)自 周賀賀，baron，代碼改變世界ctw，Arm精選， armv8/armv9，trustzone/tee，secureboot，資深安全架構(gòu)專家，11年手機(jī)安全/SOC底層安全開發(fā)經(jīng)驗。擅長trustzone/tee安全產(chǎn)品的設(shè)計和開發(fā)。文章有感而發(fā)。

說明： 在默認(rèn)情況下，本文講述的都是ARMV8-aarch64架構(gòu)，linux kernel 64位

1、背景：

隨著時代的發(fā)展、科技的進(jìn)步，安全需求的趨勢也越來越明顯，ARM也一直在調(diào)整和更新其新架構(gòu)，很多都是和安全相關(guān)的。 如下列出了一些和安全相關(guān)的架構(gòu)

1.1、ARM Trustzone的安全擴(kuò)展簡介

其中：

• (1)、AMBA-AXI總線的擴(kuò)展, 增加了標(biāo)志secure讀和寫地址線：AWPROT[1]和ARPROT[1]
• (2)、processor的擴(kuò)展(或者說master的擴(kuò)展)，在ARM Core內(nèi)部增加了SCR.NS比特位，這樣ARM Core發(fā)起的操作就可以被標(biāo)記“是以secure身份發(fā)起的訪問，還是以non-secure身份發(fā)起的訪問”
• (3)、TZPC擴(kuò)展，在AXI-TO-APB端增加了TZPC，用于配置apb controller的權(quán)限(或者叫secure controller)，例如將efuse(OTP Fuse)配置成安全屬性后，那么processor以non-secure發(fā)起的訪問將會被拒絕，非法的訪問將會返回給AXI總線一個錯誤。
• (4)、TZASC擴(kuò)展，在DDRC(DMC)之上增加一個memory filter，現(xiàn)在一般都是使用TZC400，或由SOC廠商自己設(shè)計一個這樣的IP，或叫MPU，或集成在DMC內(nèi)部，它的作用一般就是配置DDR的權(quán)限。 如果配置了DDR中某塊region為安全屬性，那么processor以non-secure發(fā)起的訪問將會被拒絕。
• (5)、MMU/Cache對安全擴(kuò)展的支持 在軟件架構(gòu)的設(shè)計中，就分為: Non-secure EL0&1 Transslation Regime 和 Secure EL0&1 Transslation Regime，即normal world和secure world側(cè)使用不同的Transslation Regime，其實就是使用不同的TTBRx_ELn寄存器，使用不同得頁表。 注意：在armv7上，TTBRx_EL0、TTBRx_EL1是banked by Security State，也就是說在安全世界和非安全世界各有一組這樣的寄存器，所以在linux和tee中可以各自維護(hù)一張自己的內(nèi)存頁表. 在armv8/armv9上，TTBRx_EL0、TTBRx_EL1不再是banked了，但是world switch時會在ATF中switch cpu context, 所以從hypervisror或os的視角來看，依然還是兩套不同的TTBRx_ELn寄存器，linux和tee各有各的頁表。 而在TLB中，又為每一個entry增加了Non-secure屬性位，即標(biāo)記當(dāng)前翻譯出的物理地址是secure還是non-secure； cache的擴(kuò)展：在cache的entry中的TAG中，有一個NON-Secure Identifier標(biāo)記為，表示當(dāng)前緩存數(shù)據(jù)的物理地址是屬于non-secure還是secure。
• (6)、gic對安全擴(kuò)展的支持，在gicv2、gicv3的版本中，都增加了對安全擴(kuò)展的支持. 以gicv3為例，將中斷劃分成了group0、secure group1和non-secure group1. 在軟件的配置下，group0和secure group1的中斷將不會target到REE(linux)中處理

1.2、ARM Trustzone的安全擴(kuò)展詳細(xì)解剖

1.3、 AMBA-AXI對Trustzone的支持

ARPROT[2:0]和AWPROT[2:0] 分別是讀通道和寫通道中的關(guān)于權(quán)限的信號，例如他們中的BIT[1]則分別表示正是進(jìn)行secure身份的讀或secure身份的寫操作。

1.4Processor的SCR.NS比特位

SCR_EL3.NS 表示當(dāng)前processor的安全狀態(tài)，NS=1表示是non-secure的，NS=0表示是Secure的

2.TZC400和TZPC簡介

TZC400接在core和(DMC)DDR之間，相當(dāng)于一個memory filter。 TZC400一般可以配置8個region（算上特殊region0, 也可以說9個），然后可以對每一個region配置權(quán)限。例如講一塊region配置成secure RW的，那么當(dāng)有non-secure的master來訪問這塊內(nèi)存時，將會被TZC擋住。

2.1 MMU對Trustzone的支持

首頁，在軟件架構(gòu)的設(shè)計中，就分為: Non-secure EL0&1 Transslation Regime 和 Secure EL0&1 Transslation Regime，即normal world和secure world側(cè)使用不同的Transslation Regime;
其實就是使用不同的TTBRx_ELn寄存器，使用不同得頁表 其次，在MMU使用的頁表中，也有NS比特位。
Non-secure Transslation Regime 只能翻譯NS=1的頁表項，secure Transslation Regime 可以翻譯NS=1和NS=0的頁表項。
即secure的頁表可以映射non-secure或secure的內(nèi)存，而non-secure的頁表只能去映射non-secure的內(nèi)存，否則在轉(zhuǎn)換時會發(fā)生錯誤 在Page Descriptor中(頁表entry中)，有NS比特位（BIT[5]），表示當(dāng)前的映射的內(nèi)存屬于安全內(nèi)存還是非安全內(nèi)存：

2.2 cache對Trustzone的支持

如下所示，以為cortex-A78為例，L1 Data Cache TAG中 ，有一個NS比特位（BIT[33]），表示當(dāng)前緩存的cacheline是secure的還是non-secure的

2.3 TLB對Trustzone的支持

如下所示，以為cortex-A78為例，L1 Data TLB entry中 ，有一個NS比特位（BIT[35]），表示當(dāng)前緩存的entry是secure的還是non-secure的

2.4 gicv的安全中斷

在gicv2/gicv3中，支持了安全中斷，配置有如下： （1）、Group分組(GICD_IGROUPRn) – gicv2 ?group0：安全中斷，由nFIQ驅(qū)動 ?group1：非安全中斷，由nIRQ驅(qū)動

（2）、Group分組(GICD_IGROUPRn)– gicv3 ?group0：安全中斷 ?non-secure group1：非安全中斷 ?secure group1：安全中斷

3.ARM Trustzone技術(shù)對軟件帶來的變化

ARM Trustzone技術(shù)對軟件框架帶來了變化

3.1、EL3 is AArch64：

3.2、EL3 is AArch32：

AArch32和AArch64 secure monitor的理解：

• 如果secureos和monitor都是64位，secureos跑在el1, monitor跑在el3;- 如果secureos和monitor都是32位，secureos和monitor都跑在EL3（secureos在svc模式、monitor在svc模式），它倆共用頁表；- 如果monitor是64位，secureos是32位，那么secureos跑在svc模式(el1)，monitor跑在el3，他倆不共用頁表

3.3、armv7：

思考：通過MMU/TLB/Cache對安全內(nèi)存攻擊的可能性

在安全架構(gòu)的設(shè)計時，我們在Core和DDR之間增加了一個TZC做為memory filter，數(shù)據(jù)流為:Core ---> TZC---->DDR, 這種架構(gòu)下，core以非安全身份發(fā)起的對安全內(nèi)存的讀寫，將會被TZC擋住。

但是這都是在理想的情況下，事實上Core發(fā)起對內(nèi)存的讀寫，未必經(jīng)過TZC未必到DDR，有可能到cache階段就完成了，即數(shù)據(jù)流變成了Core ---> MMU(TLB+Addtress Translation)---->Cache，那么這種情況下，沒有TZC的事了，你也許會說MMU/Cache中都有NS比特，但是你真的理解這里NS比特的用法嗎？ 如果core以非安全身份對安全內(nèi)存發(fā)起的讀寫時，我強(qiáng)制將MMU頁表中的安全屬性標(biāo)記位強(qiáng)制改成NS=0，會如何呢？

事實上我們只要理清原理、理清數(shù)據(jù)流 ，就不會問上面那么S13的問題了。 下面來開始剖析:

假設(shè)一個安全core 讀取了一個安全物理內(nèi)存0x2000_0000數(shù)據(jù)(虛擬地址可能是0x_xxxx_xxxx)，那么將產(chǎn)生一下行為：

• 在讀寫之前，勢必做好了MMU map，如物理地址0x2000_0000 MAP成了0x_xxxx_xxxx地址, 此時Page Descriptor中的atrribute中的NS=0- TLB緩存該翻譯，即TLB的entry中包含: 0x2000_0000、0x_xxxx_xxxx、NS=0- 安全內(nèi)存0x2000_0000數(shù)據(jù)將會被緩存到cache中，entry中的TAG包含0x2000_0000、NS=0
  同時，我有一個非安全core 發(fā)起讀寫虛擬地址0x_yyyy_yyyy，我自行修改該頁表，讓0x_yyyy_yyyy強(qiáng)制映射到安全物理內(nèi)存0x2000_0000，此時有兩種配置: (1)、0x_yyyy_yyyy—0x2000_0000, NS=0 (2)、0x_yyyy_yyyy—0x2000_0000, NS=1 我們分別看下這兩種配置，是否能讀到安全內(nèi)存： 針對(1)，非安全的core發(fā)起訪問，發(fā)現(xiàn)TLB中的條目是0x_yyyy_yyyy—0x2000_0000, NS=0,自然不會被命中，然后使用Address Translation轉(zhuǎn)換，MMU發(fā)現(xiàn)非安全的Core要來訪問安全屬性NS=0 將會被直接拒絕掉。 針對(2)，非安全的core發(fā)起訪問，由于NS=1，TLB可能會被命中，即能翻譯出0x2000_0000物理地址來，即使沒有被命中，在經(jīng)過Address Translation轉(zhuǎn)換，由于NS=1，此時也是可以正確轉(zhuǎn)換出正確的0x2000_0000物理地址。 然后接著會去cache中查詢這個地址，但是此時cache的entry中的NS=0，所以cache不會被命中，接下來就要走TZC流程了，很顯然，你一個非安全的core想訪問安全的內(nèi)存，TZC將會擋住你。

推薦

• ARMv8/ARMv9架構(gòu)從入門到精通 --博客專欄
• 《Armv8/Armv9架構(gòu)從入門到精通 第二期》 --大課程
• 8天入門ARM架構(gòu) --入門課程
  

文章來源地址http://www.zghlxwxcb.cn/news/detail-838875.html

到了這里，關(guān)于ARM TrustZone技術(shù)解析：構(gòu)建嵌入式系統(tǒng)的安全擴(kuò)展基石的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！