作者：Ricky Su，Xilinx Employee

在電影里，黑客遠(yuǎn)程控制一個(gè)城市中所有的汽車(chē)，讓它們追逐指定的目標(biāo)，這樣的場(chǎng)景讓人感覺(jué)不寒而栗。在現(xiàn)實(shí)中，某個(gè)大網(wǎng)站的用書(shū)數(shù)據(jù)泄露的新聞也已經(jīng)屢見(jiàn)不鮮。保護(hù)系統(tǒng)安全，之前是網(wǎng)絡(luò)安全工程師的職責(zé)，似乎大多數(shù)工程師不太關(guān)心這個(gè)領(lǐng)域。但其實(shí)在產(chǎn)品越來(lái)越網(wǎng)絡(luò)化、智能化的現(xiàn)在，安全的意義已經(jīng)越來(lái)越重要，畢竟我們不希望電影里黑客控制汽車(chē)的場(chǎng)景真的發(fā)生。除了汽車(chē)，任何聯(lián)網(wǎng)的設(shè)備，都會(huì)給黑客遠(yuǎn)程訪(fǎng)問(wèn)的可能性；除了放在保險(xiǎn)柜里，任何設(shè)備只要能被黑客物理接觸到，篡改系統(tǒng)或者復(fù)制系統(tǒng)也不是沒(méi)有。

在我之前接觸的客戶(hù)中，也只有少量公司在使用 Xilinx FPGA 和 SoC 芯片所提供的安全功能。其他的情況，可能是有物理環(huán)境能保證產(chǎn)品不被別人接觸到；但更多可能是工程師覺(jué)得安全功能不是必須的，或者使用安全功能太復(fù)雜。

攥寫(xiě)本文，我希望能讓大家看到：

1. 在產(chǎn)品中加入安全功能通常都是有需求的、有價(jià)值的，而且需求會(huì)越來(lái)越大。
2. 為產(chǎn)品添加安全功能，達(dá)到一定的安全級(jí)別，流程步驟和復(fù)雜程度是可控的。

就我了解到的情況，大多數(shù)使用 ZYNQ-7000 或 ZYNQ UltraScale+ MPSoC 的用戶(hù)并沒(méi)有打開(kāi) Secure Boot 功能。如果你能看完全文，照著步驟做一下，打開(kāi)安全啟動(dòng)功能，就能“免費(fèi)”提升產(chǎn)品安全等級(jí)，就是“加量不加價(jià)”啦。

上面講到“達(dá)到一定的安全級(jí)別”，是因?yàn)榘踩Ｗo(hù)是有代價(jià)的，黑客破解也是有代價(jià)的，我們需要保證以盡可能低的安全保護(hù)的代價(jià)，使黑客破解系統(tǒng)的代價(jià)比他攻破系統(tǒng)能獲取到的價(jià)值更高，這樣黑客就沒(méi)有攻擊系統(tǒng)的動(dòng)力，達(dá)到了自我保護(hù)的目的。

因此本文只描述最容易理解、用做小的代價(jià)能把 MPSoC 提供的安全啟動(dòng)的功能用起來(lái)的部分。MPSoC 的安全啟動(dòng)還可以有很多定制化的空間，更多高級(jí)功能比如 PPK Revoke 等，都可以參考本文最后列出的參考文檔，Xilinx 官方文檔中有更多詳細(xì)解釋。

全文將從以下幾個(gè)方面討論安全啟動(dòng)

一、常見(jiàn)芯片攻擊類(lèi)型與防護(hù)思路
二、MPSoC 采用的防御方法
三、實(shí)戰(zhàn)使用指南
四、常見(jiàn)問(wèn)題和錯(cuò)誤
五、參考文檔

注：本人并不是安全專(zhuān)家。本文僅是對(duì)安全啟動(dòng)的操作記錄以及對(duì)安全保護(hù)的個(gè)人理解。對(duì)于使用本文描述的方法進(jìn)行設(shè)計(jì)生產(chǎn)的后果請(qǐng)恕本人無(wú)法對(duì)其負(fù)責(zé)。技術(shù)問(wèn)題歡迎在賽靈思論壇中討論，但我不保證能全部解答，還請(qǐng)見(jiàn)諒。

一、常見(jiàn)芯片攻擊類(lèi)型與防護(hù)思路

產(chǎn)品克隆

競(jìng)爭(zhēng)對(duì)手購(gòu)買(mǎi)一份樣機(jī)，找人復(fù)制 PCB （俗稱(chēng)抄板），購(gòu)買(mǎi)到所有的元器件，復(fù)制 Flash 中的內(nèi)容，如果這樣就能讓系統(tǒng)啟動(dòng)并且完成所有預(yù)定功能，這樣就輕易完成了產(chǎn)品克隆。由于沒(méi)有研發(fā)成本，可以使用低價(jià)傾銷(xiāo)，損害產(chǎn)品設(shè)計(jì)者的利益。

現(xiàn)在的主芯片一般都有一些機(jī)制，在授權(quán)的主芯片上特制一些信息，讓Flash上的程序和芯片上的信息互相驗(yàn)證。這樣只要對(duì)方不能復(fù)制主芯片上的特制信息，就不能做到克隆。

破解軟件

當(dāng)產(chǎn)品無(wú)法直接克隆，競(jìng)爭(zhēng)對(duì)手/黑客可以通過(guò)查詢(xún)軟件具體實(shí)現(xiàn)來(lái)了解系統(tǒng)的運(yùn)行機(jī)制，尋找可能的漏洞，或者獲取受知識(shí)產(chǎn)權(quán)保護(hù)的信息。

為了不讓對(duì)方看到軟件原始信息，可以對(duì)軟件進(jìn)行加密。加密信息存在 Flash 上，芯片上電后解密后運(yùn)行。黑客僅僅讀取 Flash 上的內(nèi)容無(wú)法了解軟件原始信息。

增加惡意代碼

如果整體或部分替換 Flash 上的軟件，或讓操作系統(tǒng)運(yùn)行自己開(kāi)發(fā)的惡意代碼，有可能可以獲取到系統(tǒng)的關(guān)鍵信息。在聯(lián)網(wǎng)的設(shè)備中，惡意代碼能獲取到的信息可能會(huì)更多。在帶人工智能功能的設(shè)備上，惡意代碼能實(shí)現(xiàn)的破壞力也可能比傳統(tǒng)的攻擊更嚴(yán)重。因此控制軟件運(yùn)行權(quán)限，確保只有授權(quán)應(yīng)用能夠運(yùn)行，不讓非授權(quán)的應(yīng)用在系統(tǒng)中運(yùn)行，對(duì)系統(tǒng)安全也非常重要。

認(rèn)證，或者稱(chēng)為授權(quán) （Authentication) ，是防止惡意代碼運(yùn)行的重要步驟。

打磨芯片獲取密鑰

加密和認(rèn)證一般的實(shí)現(xiàn)方法都是通過(guò)在芯片內(nèi)部布置只可以燒寫(xiě)一次的反熔絲，用這些熔絲位來(lái)非易失地存儲(chǔ)密鑰。反熔絲相對(duì)普通邏輯來(lái)說(shuō)是區(qū)別比較明顯的，理論上來(lái)說(shuō)，打開(kāi)芯片封裝后是有可能通過(guò)顯微鏡是有可能查找出反熔絲的密鑰位，然后用它解密的。

要防護(hù)通過(guò)這種方式獲取密鑰，主要有兩種方法：
1. 采用非對(duì)稱(chēng)方式的公鑰-私鑰對(duì)，在芯片中只存儲(chǔ)公鑰，或公鑰的Hash。對(duì)方獲得公鑰是沒(méi)有意義的。
2. 對(duì)于必須采用對(duì)稱(chēng)加密的方式，可以將密鑰再次加密。只要再次加密的密鑰只能通過(guò)某種不能被窺探的方法解密成原始密鑰，就可以防護(hù)這種方式。

旁路攻擊

所謂旁路攻擊，就是攻擊者并不真正“看”到存儲(chǔ)在芯片中的密鑰，而是通過(guò)其他方式計(jì)算出來(lái)。一個(gè)比較容易理解的例子就是最近在網(wǎng)絡(luò)上流行一個(gè)應(yīng)用，通過(guò)電腦的麥克風(fēng)采集音頻，算出敲擊鍵盤(pán)的字符。采集的信息不是直接從鍵盤(pán)的輸入的來(lái)，而是從麥克風(fēng)得來(lái)，就是一種旁路攻擊。

對(duì)于獲取芯片密鑰的旁路攻擊，比較常見(jiàn)的是通過(guò)監(jiān)測(cè)電源功耗的簡(jiǎn)單功耗分析、差分功耗分析。

要防止類(lèi)似的旁路攻擊，防護(hù)思路主要是讓一個(gè)密鑰所對(duì)應(yīng)的解密數(shù)據(jù)盡可能少，這樣就能避免攻擊者采集到足夠多的用于統(tǒng)計(jì)的信息。

二、MPSoC 采用的防御方法

攻擊方法 防御方式 MPSoC 上的對(duì)應(yīng)硬件和措施

注意：這里提到的防御方式和 MPSoC 上的對(duì)應(yīng)硬件措施并不是完備的列表，只是實(shí)際應(yīng)用中最常用的方式。

比如 MPSoC 上儲(chǔ)存密鑰還可以存在 BBRAM (Battery Backed RAM) 中，系統(tǒng)掉電可以繼續(xù)保存密鑰，而且由于它基于 RAM 結(jié)構(gòu)，不是 eFUSE，所以即使打開(kāi)芯片也不能獲取到密鑰。但大多數(shù)系統(tǒng)都不能容忍產(chǎn)品發(fā)布后，支持 BBRAM 的電池耗盡后，系統(tǒng)無(wú)法啟動(dòng)的限制，因此暫不介紹。

什么是 AES Black Key

AES 是一種對(duì)稱(chēng)加密技術(shù)。所謂對(duì)稱(chēng)加密，就是加密和解密用的是同一個(gè)密鑰。這樣的話(huà)，保護(hù)密鑰就變得尤為重要。把 AES Key 直接燒錄到 eFUSE 中被稱(chēng)為 Red Key，如果有人能夠打開(kāi)芯片探測(cè)到 eFUSE 的燒錄情況，就可以獲得密鑰。為了防止這種情況發(fā)生，Xilinx 提供了 Black Key 方案。

每片 MPSoC 芯片中都有一個(gè)硬件模塊叫做 PUF: Physical Uncloneable Function。它可以根據(jù)每片芯片物理上本身工藝尺度上的微小差異，對(duì) Red Key 進(jìn)行加密生成 Black Key。當(dāng) Black Key 燒錄在 eFUSE 后，這片芯片的 PUF 模塊通過(guò)一些輸入信息還可以將 Red Key 還原回來(lái)，再用得到的 Red Key 解密安全啟動(dòng)的鏡像。因?yàn)闊浽?eFUSE 中的是 Black Key 而不是 Red Key，它不能通過(guò)簡(jiǎn)單的方法還原出黑客希望獲得的密鑰來(lái)解密鏡像，整個(gè)解密過(guò)程只能在芯片內(nèi)部進(jìn)行，使用 Black Key 技術(shù)相當(dāng)于為產(chǎn)品的安全再增加了一堵墻。

什么是 Key Rolling

像功耗分析這樣的旁路攻擊，是通過(guò)統(tǒng)計(jì)學(xué)原理從密文推算出密鑰，再還原成原文。為了不給攻擊者足夠的信息推算密鑰，Key Rolling 的主要想法是一個(gè)密鑰只用于有線(xiàn)長(zhǎng)度的原文。原文切成很多小份，每一小份原文加一個(gè)新的密鑰打包后用密鑰加密，新的密鑰用于加密后面的一份原文和密鑰，這樣滾動(dòng)前進(jìn)。

解密時(shí)就反向操作，eFUSE 里的密鑰只用于解密 section 1，解密出原文1 和密鑰1，再用密鑰1 解密 section 2，得到原文2 和密鑰2，依此類(lèi)推。

了解了基本的攻擊路數(shù)和防御方法，會(huì)感覺(jué)到這些方法其實(shí)就是魔高一尺道高一丈。很多防御功能都已經(jīng)內(nèi)置在芯片里了，使用成本很低，只要把他們用起來(lái)，就能把自己的知識(shí)產(chǎn)權(quán)保護(hù)起來(lái)。下面我們就了解一下怎么做實(shí)戰(zhàn)操作。

三、全局觀：做一個(gè)適合你的安全啟動(dòng)的方案

做一個(gè)安全啟動(dòng)方案，可能涉及到做許多選擇和決定。每一個(gè)決定，都有一定的選擇依據(jù)。

第一個(gè)選擇：要保護(hù)哪些內(nèi)容

要知道需要保護(hù)哪些內(nèi)容，先要知道有哪些內(nèi)容可以保護(hù)。在一個(gè)通常的 MPSoC 設(shè)計(jì)中，軟件邏輯組件有這些：

• FSBL
• PMU Firmware (PMUFW)
• ARM Trusted Firmware (ATF)
• FPGA Bit File
• U-boot
• Linux Kernel + device tree + rootfs
• User Data (Used by u-boot or Linux)

啟動(dòng)加載流程有些可以調(diào)換，但主要是通過(guò)以上的順序加載的。FPGA Bit 可以在 FSBL、 U-boot、 Linux 階段被加載。

每一個(gè)組件都可以選擇 1) 同時(shí)做認(rèn)證和加密 2) 只做認(rèn)證 3) 只做加密 4) 什么都不做 (就是 Non-secure boot)。

上面的四種選項(xiàng)意味著，加密和認(rèn)證是兩個(gè)獨(dú)立的變量。但實(shí)際使用中“只做加密”這種情況比較少用到。由于 MPSoC 中有硬件加速的 RSA 認(rèn)證模塊，認(rèn)證對(duì)啟動(dòng)時(shí)間的影響比較低；由于認(rèn)證的機(jī)制就是在鏡像最后加上checksum，對(duì)存儲(chǔ)空間的需求也很低，所以即使只需要加密功能，順便也把認(rèn)證功能加上了。

對(duì)于安全啟動(dòng)有一個(gè)概念叫做 Root of Trust，信任是要從根部就開(kāi)始的，或者叫 Chain of Trust，信任鏈，都是一個(gè)意思。要保證某個(gè)步驟是安全可靠的，必須前面所有的步驟都是安全可靠的。比如某個(gè)應(yīng)用場(chǎng)景需要保證 FPGA Bit 文件是安全可靠的，Bit 文件是 U-boot 加載的，那么 Bit 文件和從啟動(dòng)到加載 Bit 文件之前的所有步驟都需要經(jīng)過(guò)認(rèn)證，之后的可以不做，在這個(gè)例子中， FSBL，PMUFW，ATF，U-boot 和 Bit 都需要經(jīng)過(guò)認(rèn)證，Linux 不一定需要。

有一種說(shuō)法是，如果代碼完全是開(kāi)源的，不包含用戶(hù)的知識(shí)產(chǎn)權(quán)，那么這個(gè)部分可以只做認(rèn)證，不做加密，以盡可能少地用到 eFUSE 中的 AES Key；但另一種想法認(rèn)為，沒(méi)修改的就不加密，就等于暴露了自己沒(méi)有修改開(kāi)源代碼這件事，而這個(gè)信息本身也是有價(jià)值的。兩種說(shuō)法都有道理，怎么選擇看自己取舍吧。

第二個(gè)選擇：怎樣打包組件

打包的時(shí)候，可以把所有內(nèi)容整個(gè)一起打包成 Boot.bin，UG1209 中的例子就是這樣做的，這樣做完整的安全啟動(dòng)最容易實(shí)現(xiàn)，但也意味著這些內(nèi)容都不可以隨意動(dòng)態(tài)變更，每次重啟系統(tǒng)恢復(fù)到原樣。一般特定功能的嵌入式系統(tǒng)傾向這種設(shè)計(jì)。

但開(kāi)放式系統(tǒng)不允許這中完整打包，每次復(fù)原的設(shè)計(jì)。用戶(hù)可能希望把在系統(tǒng)中做的操作保存在 Flash 中，重啟后仍然能夠訪(fǎng)問(wèn)到。于是另一種常見(jiàn)方案是從 FSBL 到 u-boot 用認(rèn)證加密的方式打包成一個(gè) Boot.bin，Linux 部分存在獨(dú)立的 Flash 分區(qū)中。怎么保證可讀寫(xiě)的 Linux 分區(qū)安全是另一個(gè)復(fù)雜的話(huà)題，用戶(hù)場(chǎng)景和解決方法也多種多樣，就像醫(yī)生得看到病人才能開(kāi)藥，具體怎么做沒(méi)辦法簡(jiǎn)單一句概括，有機(jī)會(huì)后續(xù)再聊了。

如果將所有內(nèi)容都打包進(jìn) Boot.bin，這樣 Boot.bin 可能很大，一個(gè)典型的PetaLinux Kernel + Rootfs 有大約60MB，加上 MPSoC 的 Bit 文件大約 10-20 MB，如果需要再添加一些應(yīng)用程序，可能一套 Boot.bin 有100MB。如果需要一個(gè)功能完整的 Linux，甚至可能到 1GB。這就對(duì) Flash 容量有一些挑戰(zhàn)，現(xiàn)在最大的 QSPI 芯片只有 128MB，如果 Boot.bin 超過(guò)了 QSPI Flash 容量，就只能選其他啟動(dòng)方式，比如 eMMC。由于使用 NOR Flash 技術(shù)的 QSPI 比使用 NAND 技術(shù)的 eMMC和 SD 更可靠一些，如果考慮到可靠性一定要用 QSPI Flash 啟動(dòng)，就可以將除了 Linux 以外的部分打包成 Boot.bin，放在 QSPI Flash，Linux 部分放在其他介質(zhì)，比如 eMMC 或 SD 卡。

第三個(gè)選擇：在哪一步做安全認(rèn)證和解密

前面講到一個(gè)例子，F(xiàn)PGA Bit 可以由 FSBL、U-boot 或 Linux 加載。如果有用戶(hù)自定義數(shù)據(jù)需要在安全啟動(dòng)過(guò)程中加載，也可以用同樣的流程。

最終做認(rèn)證和解密的都是 PMU。選擇在哪一步加載，就需要在這步調(diào)用安全啟動(dòng)的 API，與 PMU 通信，由 PMU 進(jìn)行認(rèn)證、解密后再加載。

• 由 FSBL 加載的組件需要都打包在 Boot.bin 中，打包過(guò)程中指定每個(gè)組件的加密、認(rèn)證方式，F(xiàn)SBL 會(huì)根據(jù)這些配置在運(yùn)行時(shí)做認(rèn)證和解密。
• U-boot 定義了一套 API 與 PMU 通信，將認(rèn)證和解密的任務(wù)交給 PMU 執(zhí)行。如果需要 U-boot 過(guò)程中認(rèn)證、解密，需要使用 Xilinx 特殊的 U-boot 命令 zynqmp secure。打包 U-boot 能識(shí)別的安全組件也是通過(guò) bootgen，與上面 Boot.bin 的打包方式類(lèi)似。普通文件和 FPGA Bit 都可以打包成 Boot.bin 供 U-boot 加載。具體方法說(shuō)明見(jiàn)參考文檔5。
• Linux 和 U-boot 類(lèi)似，都是通過(guò)驅(qū)動(dòng)與 PMU 通信。但是截至到目前最新版本 (2018.3)，Linux 只支持對(duì) FPGA Bit 文件進(jìn)行認(rèn)證、解密后直接加載，不支持用戶(hù)數(shù)據(jù)的認(rèn)證和解密。具體操作方法見(jiàn)參考文檔6。

三個(gè)選擇全都做完，用戶(hù)可以自己整理出一個(gè)表格，比如這樣：

組件 認(rèn)證 加密 打包

FSBL	Y	Y	Boot.bin
PMUFW	Y	Y	Boot.bin
ATF	Y	Y	Boot.bin
U-Boot	Y	Y	Boot.bin
Linux Kernel	Y	Y	image.ub.bin
Linux Device Tree	Y	Y	image.ub.bin
Linux RootFS	Y	Y	image.ub.bin

FSBL、PMUFW、ATF、U-boot 打包成 Boot.bin，所有組件全都進(jìn)行認(rèn)證和加密。Linux 的各組件由 PetaLinux 打包成 image.ub，用 bootgen 整體進(jìn)行認(rèn)證和加密，生成 image.ub.bin。

沒(méi)有后悔藥：安全為上的測(cè)試流程

由于 eFUSE 只可以燒寫(xiě)一次，如果由于不熟悉流程，設(shè)置出錯(cuò)的話(huà)會(huì)導(dǎo)致芯片無(wú)法正常使用，因此燒寫(xiě) eFUSE 需要比較謹(jǐn)慎，盡量先把需要驗(yàn)證的部分驗(yàn)證通過(guò)，最后才真正在 eFUSE 中燒寫(xiě)密鑰和對(duì)應(yīng)的設(shè)置位。

為了讓用戶(hù)能夠再不燒寫(xiě) eFUSE 的情況下提前能驗(yàn)證流程以及密鑰的組合，Xilinx 提供了 Boot Header 方法，簡(jiǎn)稱(chēng) BH。在生成鏡像的時(shí)候，將密鑰暫存于鏡像的頭部。啟動(dòng)時(shí)，軟件從鏡像頭部尋找密鑰，跳過(guò)從 eFUSE 硬件讀取的過(guò)程。BH 流程會(huì)使用鏡像頭部中暫存的密鑰與鏡像匹配進(jìn)行認(rèn)證和解密操作。用戶(hù)可以在熟悉BH流程后，最后再將密鑰燒錄到 eFUSE 中。

注意：
1. Boot Header 流程是可選的，不是必須的。它只是給用戶(hù)檢驗(yàn)流程用的。既做 BH 流程又做 eFUSE 流程可能會(huì)把人弄暈，如果真是這樣的話(huà)建議不要做 BH 流程直接做 eFUSE 流程。

2. Boot Header 流程不可以用在真實(shí)產(chǎn)品中，因?yàn)槊荑€在鏡像頭部，仍然可以被提取。

總體測(cè)試流程可以梳理為以下步驟：

1. 確認(rèn)自己的安全啟動(dòng)模式：每個(gè)組件用那種加密模式和認(rèn)證模式，可以列成一個(gè)表格。AES 使用 Black Key 還是 Red Key；AES Only 還是 AES + RSA；Key 存在 eFUSE 還是 BBRAM 等。

2. 生成所需的密鑰

• RSA Private Key 和 Public Key
• AES Key 0 （用于燒錄 eFUSE 的 Key）

3. （可選）用 BH 模式生成 BOOT.BIN，進(jìn)行 RSA 和 AES 在 Boot Header 中的測(cè)試

4. 用 eFUSE 模式生成 BOOT.BIN

5. 將 BOOT.BIN 寫(xiě)入 SD 卡或 Flash

6. 從 JTAG 模式啟動(dòng)，將 RSA PPK Hash 和 AES Key (red or black) 寫(xiě)入 eFUSE。用 Flash/SD 模式重啟后驗(yàn)證安全啟動(dòng)流程。 a) RSA PPK 和 AES Red Key 可以同時(shí)寫(xiě)入 b) 如果使用 AES Black Key，分別使用兩個(gè)程序，先燒錄 Blackkey （這個(gè)過(guò)程稱(chēng)為 PUF Registration），再燒錄 RSA PPK Hash

注意：如果啟動(dòng)模式是 SD 卡，萬(wàn)一鏡像和 eFUSE 中的密鑰不匹配，由于更換 SD 卡中的啟動(dòng)鏡像比較容易，那么多次嘗試也不會(huì)遇到什么困難。與之相對(duì)，如果啟動(dòng)設(shè)備只有 Flash，則需要先燒錄 Flash 后燒錄密鑰，因?yàn)闊浢荑€后 JTAG 將不能使用，不能再使用 SDK 自帶的 Flash Programmer 工具燒錄 Flash。如果燒錄 Flash 的鏡像錯(cuò)誤，無(wú)法完成安全啟動(dòng)，但是 eFUSE 又已經(jīng)燒錄，只能通過(guò)焊接更換 Flash，離線(xiàn)燒錄正確的鏡像，再焊接回板上，才能繼續(xù)使用這個(gè)系統(tǒng)。

四、實(shí)戰(zhàn)使用指南

以下幾種典型使用模式中，生成密鑰和生成加密鏡像的流程都是一樣的，不同的是需要使用不同的 BIF 配置文件。生成工具是 Vivado 或 SDK 中的命令行小工具 bootgen。燒錄 eFUSE 使用 SDK 中自帶的例子程序，只需要對(duì)頭文件進(jìn)行很少的修改，就能執(zhí)行。如果使用 Blackkey，額外需要一個(gè)注冊(cè)的操作，輸入 red key，運(yùn)行程序時(shí) MPSoC 產(chǎn)生 Black Key。

讓 FSBL 能打印出詳細(xì)啟動(dòng)信息

在調(diào)試階段，主要的安全啟動(dòng)狀態(tài)信息是由 FSBL 打印出來(lái)的。默認(rèn) FSBL 并不打印詳細(xì)調(diào)試信息，需要在 FSBL 編譯的時(shí)候定義 FSBL_DEBUG_INFO，才會(huì)有詳細(xì)信息打印。

生成密鑰和鏡像

這一節(jié)主要描述這幾件事：Bootgen 工具、BIF 描述文件和密鑰文件。

BOOTGEN 命令

Bootgen 可以實(shí)現(xiàn)很多功能，最主要的功能是產(chǎn)生用于啟動(dòng)的 Boot.bin。它可以用來(lái)生成帶安全啟動(dòng)功能的鏡像，也可以是不帶安全啟動(dòng)功能的。以下是我們?cè)谥谱靼踩珕?dòng)功能 Boot.bin 時(shí)常用的一步到位命令：

bootgen -arch zynqmp -image secureboot.bif -efuseppkbits ppk0_digest.txt -w -o BOOT.bin -encryption_dump

1. 指定 ZYNQ UltraScale+ MPSoC 架構(gòu)。具體哪個(gè)型號(hào)的芯片不用關(guān)心。

2. image 選項(xiàng)指定輸入文件。BIF 是 Boot.bin 結(jié)構(gòu)的描述文件，后面章節(jié)馬上就會(huì)介紹。

3. efuseppkbits 選項(xiàng)將為 RSA Primary Public Key 產(chǎn)生 Hash，并保存到指定文件。這個(gè) Hash 是將要寫(xiě)入 eFUSE 在 RSA 認(rèn)證時(shí)使用的。

4. o 指定輸出的 Boot.bin 文件名，w表示可以覆蓋文件。

5. encryption_dump 指定將每個(gè)分區(qū) AES 加密的詳細(xì)過(guò)程輸出到 aes_log.txt 中。

6. 所謂“一步到位”命令，就是它能只能識(shí)別 BIF 中所指定的密鑰文件是否已經(jīng)存在，以及互相之間是否匹配。如果

• 如果密鑰已經(jīng)存在，bootgen 會(huì)使用現(xiàn)有密鑰
• 如果密鑰不存在，或部分不存在，bootgen 會(huì)生成所有需要的密鑰
• 如果發(fā)現(xiàn)已有密鑰不符合規(guī)則，比如所有 AES Key nky 文件的的 Key 0 不一致，bootgen 會(huì)報(bào)告錯(cuò)誤，因?yàn)?Key 0 指的是將要寫(xiě)入 eFUSE 的密鑰，所有分區(qū)的 Key 0 必須一致。

如果只需要其中某一步操作結(jié)果，這些參數(shù)也可以分開(kāi)使用。
bootgen -p zcu9eg -arch zynqmp -image secureboot.bif // 生成 Key
bootgen -p zcu9eg -arch zynqmp -efuseppkbits ppk0_digest.txt -image secureboot.bif // 生成 PPK Hash
bootgen -p zcu9eg -arch zynqmp -image secureboot.bif -w -o BOOT.bin -encryption_dump // 生成 BOOT.BIN 和 aes_log.txt

BIF 結(jié)構(gòu)

BIF 是 bootgen 的輸入描述文件。它描述了需要生成 boot.bin 的結(jié)構(gòu)，比如 boot.bin 中有哪些 partition，每個(gè) partition 的源來(lái)自哪些文件，這些 partition 由誰(shuí)引導(dǎo)，會(huì)在哪個(gè) target device 上運(yùn)行，怎樣認(rèn)證，以及怎樣加密。基本它就是上述第三章總結(jié)的表格的文字描述。

BIF 的結(jié)構(gòu)大致是這樣
the_ROM_image:
{
[文件屬性]文件名
[參數(shù)類(lèi)型]參數(shù)值
}

具體的文件屬性、參數(shù)類(lèi)型、參數(shù)值的可選項(xiàng)，可以參考 UG1137 第 16 章。

參考的 BIF: 使用 RSA + AES (Red Key)
the_ROM_image:
{
[pskfile]psk0.pem
[sskfile]ssk0.pem
[auth_params]spk_id = 0; ppk_select = 0
[keysrc_encryption]efuse_red_key
[fsbl_config]a53_x64
[aeskeyfile]red.nky
[bootloader, authentication = rsa, encryption = aes]FSBL_1112.elf
[aeskeyfile]pmu_fw.nky
[destination_cpu = pmu, authentication = rsa, encryption = aes]pmu_fw.elf
[aeskeyfile]fpga.nky
[destination_device = pl, authentication = rsa, encryption = aes]top.bit
[destination_cpu = a53-0, exception_level = el-3, trustzone, authentication = rsa]bl31.elf
[aeskeyfile]uboot.nky
[destination_cpu = a53-0, exception_level = el-2, authentication = rsa, encryption = aes]u-boot.elf
}

用本章第一節(jié)的 Bootgen 命令就能生成 Boot.bin。

從上面的BIF的例子中可以看到：

• 所有 Partition 都加密了，每個(gè) Partition 都對(duì)應(yīng)了一個(gè) nky 文件，這些 nky 文件的 Key 0 一致， Key 1 各不相同。Key 0 解出 Key 1，然后 Key 1 解密對(duì)應(yīng)的 Partition。
• 當(dāng) PMUFW 和 FSBL 都加密的情況下，PMUFW 需要由 FSBL 來(lái)加載，而不是由 CSU BootROM 來(lái)加載，所以使用了 [destination_cpu = pmu]，而不是[pmufw_image]。參考 AR 70622
• Bit 文件需要加密的情況下，Bit 要寫(xiě)在 ATF (bl31.elf) 的前面，因?yàn)榻饷?Bit 需要用的 OCM 空間與存放 ATF 的空間是同一個(gè)。參考 UG1137 v8.0 P114

參考的 BIF: 使用 RSA + AES (Black Key)
the_ROM_image:
{
[pskfile]psk0.pem
[sskfile]ssk0.pem
[auth_params]spk_id = 0; ppk_select = 0
[keysrc_encryption]efuse_blk_key
[fsbl_config]a53_x64
[aeskeyfile]red.nky
[bootloader, authentication = rsa, encryption = aes]FSBL_1112.elf
[aeskeyfile]pmu_fw.nky
[destination_cpu = pmu, authentication = rsa, encryption = aes]pmu_fw.elf
[aeskeyfile]fpga.nky
[destination_device = pl, authentication = rsa, encryption = aes]top.bit
[destination_cpu = a53-0, exception_level = el-3, trustzone, authentication = rsa]bl31.elf
[aeskeyfile]uboot.nky
[destination_cpu = a53-0, exception_level = el-2, authentication = rsa, encryption = aes]u-boot.elf
[bh_key_iv] black_iv.txt
}

Black Key 的 BIF 與 Red Key 相比只有微小的改動(dòng)：

• [keysrc_encryption]改為了efuse_blk_key
• 最后增加了[bh_key_iv]，一個(gè) Initialization Vector。

如果只想做非破壞性的實(shí)驗(yàn)，請(qǐng)用附3中著名“Boot Header”的例子BIF。

燒錄鏡像

接下來(lái)我們先燒錄鏡像到 Flash，再燒錄密鑰到 eFUSE。如果使用 QSPI Flash, NAND Flash 或 eMMC 啟動(dòng)，由于燒錄密鑰后 JTAG 將無(wú)法方便地使用，先燒鏡像會(huì)方便很多。如果使用 SD 卡啟動(dòng)，先后沒(méi)有關(guān)系。

這一步和非安全啟動(dòng)的操作一樣，只是將燒錄的內(nèi)容替換成上一節(jié)產(chǎn)生的帶有安全啟動(dòng)功能的 Boot.bin。這個(gè) Boot.bin 至少帶有 u-boot，因此后續(xù)如果還需要燒寫(xiě)更多內(nèi)容，也會(huì)比較方便。

燒錄 Flash 可以用 SDK 自帶的工具 SDK -> Xilinx Tools -> Program Flash，也可以使用 u-boot。U-boot 可以事先存放在 Flash 或 SD 卡中，或者使用這個(gè)腳本從 JTAG 加載 u-boot。

燒錄密鑰 生成密鑰燒錄程序

燒錄密鑰不需要使用特殊的軟硬件工具，只需要在 MPSoC 上運(yùn)行一個(gè) Standalone 程序。這個(gè)程序可以用 Xilinx Software Development Kit (SDK) 生成。

Xapp1333 的 RSA eFUSE Configuration 章節(jié)很詳細(xì)地描述了怎樣在 SDK 中生成 xilskey_efuseps_zynqmp_example 以及配置頭文件的過(guò)程。這個(gè)例子程序可以燒錄 RSA Key 和/或 AES Red Key。Black Key 需要用下面一節(jié)講的 xilskey_puf_registration 程序。

簡(jiǎn)要描述流程就是：

1. 創(chuàng)建 SDK Workspace, 導(dǎo)入 Vivado HDF 文件
2. 在 BSP Settings 中使能 Library: XilSKey 和 XilSecure
3. 雙擊 BSP 的 MSS 文件，找到 Library - XilSKey, 在 Import Examples 彈出的對(duì)話(huà)框中選擇需要導(dǎo)入的例子程序

• RSA 和 AES Red Key 使用 xilskey_efuse_zynqmp_example
• AES Black Key 使用 xilskey_puf_registration

4. 修改例子程序中的頭文件中的參數(shù)，以符合自己的需求
5. 編譯工程，在板上運(yùn)行，觀察串口輸出

• 如果使用 Black Key，先運(yùn)行 xilskey_puf_registration，再運(yùn)行xilskey_efuse_zynqmp_example

頭文件中每個(gè)參數(shù)的意義在頂部都有詳細(xì)解釋。某些參數(shù)僅在使能了其他參數(shù)時(shí)才有效，具體可以參考C代碼，并不是很難讀。在這里對(duì)必要的選項(xiàng)做個(gè)概述。

使用 RSA + AES Red Key 的方案，要修改 xilskey_efuse_zynqmp_example 中 RSA 的部分參數(shù)和 AES 部分參數(shù)；使用 RSA + AES Black Key 的方案，要修改 xilskey_efuse_zynqmp_example 中 RSA 的部分參數(shù)和 xilskey_puf_registration 中的部分參數(shù)。

xilskey_efuse_zynqmp_example 中 RSA 的部分參數(shù)。

參數(shù) 目標(biāo)值 說(shuō)明

XSK_EFUSEPS_RSA_ENABLE	TRUE	燒寫(xiě) RSA_ENABLE 位。燒錄后沒(méi)有 RSA 功能的 Boot.bin 將不能啟動(dòng)系統(tǒng)；JTAG 也只有在啟動(dòng)成功后才能使用
XSK_EFUSEPS_WRITE_PPK0_HASH	TRUE	燒錄 RSA PPK0 Hash
XSK_EFUSEPS_PPK0_HASH	上文 ppk0_digest.txt 中的內(nèi)容	由 Bootgen 產(chǎn)生的 PPK0 的 SHA3 Hash
XSK_EFUSEPS_PPK0_IS_SHA3	TRUE	bootgen 默認(rèn)生成 SHA3 Hash

xilskey_efuse_zynqmp_example 中 AES Red Key 的部分參數(shù)：

參數(shù) 目標(biāo)值 說(shuō)明

XSK_EFUSEPS_RSA_ENABLE	TRUE	燒寫(xiě) RSA_ENABLE 位。燒錄后沒(méi)有 RSA 功能的 Boot.bin 將不能啟動(dòng)系統(tǒng)；JTAG 也只有在啟動(dòng)成功后才能使用
XSK_EFUSEPS_WRITE_AES_KEY	TRUE	燒錄 AES Key
XSK_EFUSEPS_AES_KEY	red.nky 中的 Key 0

xilskey_puf_registration 中需要修改的部分參數(shù)：

參數(shù) 目標(biāo)值 說(shuō)明

XSK_PUF_INFO_ON_UART	TRUE	輸出打印到串口
XSK_PUF_PROGRAM_EFUSE	TRUE	燒錄 RSA PPK0 Hash
XSK_PUF_PROGRAM_SECUREBITS	TRUE	由 Bootgen 產(chǎn)生的 PPK0 的 SHA3 Hash
XSK_PUF_AES_KEY	red.nky 中的 Key 0	bootgen 默認(rèn)生成 SHA3 Hash
XSK_PUF_IV	任意	完全任意，與其他值沒(méi)有關(guān)系

在真實(shí)量產(chǎn)環(huán)境中，最好也將以下的鎖鎖上，因?yàn)?eFUSE 的燒錄是用反熔絲技術(shù)將 0 改寫(xiě)成 1，沒(méi)有燒錄過(guò)的比特仍然能繼續(xù)修改，知道所有比特都是1為止。將 LOCK 設(shè)置為 1 后，對(duì)應(yīng)的 eFUSE 比特就無(wú)法再改寫(xiě)，達(dá)到最高的安全性。

xilskey_efuse_zynqmp_example 中防止 eFUSE 再次寫(xiě)入的鎖

參數(shù) 目標(biāo)值 說(shuō)明

XSK_EFUSEPS_PPK0_WR_LOCK	TRUE	防止再次寫(xiě)入 PPK0
XSK_EFUSEPS_AES_WR_LOCK	TRUE	防止再次寫(xiě)入 AES Key

xilskey_puf_registration中的鎖

參數(shù) 目標(biāo)值 說(shuō)明

XSK_PUF_PROGRAM_SECUREBITS	TRUE	后續(xù)幾個(gè)鎖將被寫(xiě)入
XSK_PUF_SYN_WRLK	TRUE	防止再次寫(xiě)入 syndrome data

xilskey_efuse_zynqmp_example 默認(rèn)的燒錄流程中如果只燒錄 RSA Key（XSK_EFUSEPS_RSA_ENABLE == TRUE）而沒(méi)有燒錄 AES Key，AES Key CRC Check 仍然會(huì)執(zhí)行，如果此時(shí) AES Key 并沒(méi)有燒錄過(guò)，會(huì)報(bào)告錯(cuò)誤而退出程序。手工修改代碼，注釋掉這部分即可。2018.2 中仍然有以上問(wèn)題，后續(xù)版本中會(huì)修復(fù)。

eFUSE 燒錄完成后，斷電重啟，就能看到帶安全啟動(dòng)功能的Boot.bin中FSBL打印出的內(nèi)容了。

讓 U-boot 加載安全啟動(dòng)文件

下面將嘗試只在 Boot.bin 中啟動(dòng)到 U-boot，讓 U-boot 在繼續(xù)保持安全的模式下，獲取 Bit 和 Linux 文件，進(jìn)一步進(jìn)行啟動(dòng)。這樣做的好處是 Linux 和 FPGA Bit 不需要打包到 Boot.bin 中，有利于升級(jí)時(shí)的文件管理，也可以將不同的部分存放在不同的 Flash 中，降低對(duì)啟動(dòng) Flash 的容量要求。

U-boot 可以調(diào)用 PMU 對(duì)安全啟動(dòng)文件進(jìn)行認(rèn)證和解密，可以用來(lái)獲取簽名且加密的 FPGA Bit 文件、Linux 鏡像或用戶(hù)自定義數(shù)據(jù)。使用步驟分為兩步：制作文件和加載。具體過(guò)程在Xilinx Wiki - Authentication and decryption at u-boot中有詳細(xì)解釋。

制作能讓 U-boot 加載的安全啟動(dòng)文件

像上文一樣通過(guò)寫(xiě)一個(gè)BIF文件描述需要簽名和加密的源文件，經(jīng)過(guò) bootgen 就能產(chǎn)生安全啟動(dòng)文件。至于 BIF 的寫(xiě)法，基本和上文上電啟動(dòng)時(shí)一致，只是我們一般不需要 FSBL, PMUFW 和 ATF，去掉那些段即可。

bootgen 命令的使用方法也一致：
bootgen -image Data.bif -w -o Output.bin -arch zynqmp

U-boot 加載安全啟動(dòng)文件

對(duì)于數(shù)據(jù)文件，比如 Linux 鏡像，使用 zynqmp 命令加載：

zynqmp secure

對(duì)于 Bit 文件，使用 fpga load 命令加載:
fpga loads [dev] [address] [size] [auth] [enc] [Userkey address]

關(guān)于每個(gè)參數(shù)的意義，請(qǐng)參考 Wiki 中的詳細(xì)解釋。

附錄

附1： RSA Key 樣例

Bootgen 可以根據(jù)類(lèi)似 [pskfile]psk0.pem的 BIF 描述生成 RSA Key psk0.pem。如果密鑰文件已經(jīng)存在，bootgen 就會(huì)使用這個(gè)密鑰，而不會(huì)生成新密鑰。

RSA Private Key psk0.pem 大致內(nèi)容如下
-----BEGIN RSA PRIVATE KEY-----
bi4TvfJuikXSAjJ3XoHDCwGZ8SerGMKSJ8gPWFbN/Ay0x27qBGaoAUNjySyWRPQC
...
tWnmtk/l6E1kGvZXvGRr1BJSDh3IV4k/LehTj+zSHD/vZ0GNFUjqAC4RbEkj7t17
-----END RSA PRIVATE KEY-----

附2： AES Key 樣例

Bootgen 可以根據(jù) [aeskeyfile]key.nky生成 AES Key 文件: key.nky。

AES Key 大致內(nèi)容如下：
Device zcu9eg;

Key 0 A98B3BC6BBA48E2F992C20DB28CB498EB17F3B8D9219AAB6689B726A107F8A70;
IV 0 F18CAED66C8BDA74F8A2DC65;

Key 1 630A30B2815E2518792B3C0CAD84824D7B61586030EE0648FCE363DBC0C03234;
IV 1 43BE7AAAD6631BDB692EB64F;

其中 Key 0 是將要燒錄到 eFUSE 中的 AES Key。

啟動(dòng)時(shí)用 eFUSE 中的 AES Key 解密存于 boot header 中的已經(jīng)加密了的 Key 1，得到 Key 1 后再用 Key 1 解密這個(gè) Partition。這樣保證盡可能少地使用 eFUSE 中的 AES Key，防止 DPA 攻擊。

附3：常見(jiàn)用法的 BIF 例子

• BIF File with eFUSE Red Key: UG1137 (v8.0) P103
• BIF File with an Operational Key: UG1137 (v8.0) P103
• BIF File for Black Key Stored in eFUSE: UG1137 (v8.0) P106
• BIF File for Black Key Stored in Boot Header: UG1137 (v8.0) P107
• Bif File for Obfuscated Form (Gray) key stored in eFUSE: UG1137 (v8.0) P107
• BIF File with SHA-3 eFUSE RSA Authentication and PPK0: UG1137 (v8.0) P112

五、常見(jiàn)問(wèn)題和錯(cuò)誤

只燒 RSA Key，不燒 RSA_EN，導(dǎo)致 FSBL 無(wú)法啟動(dòng)后續(xù) partition

要讓帶 RSA 認(rèn)證的 Image 成功啟動(dòng)，必須將 RSA Key 和 RSA_EN 的 eFUSE 位全部燒錄。只燒錄 RSA Key 不燒錄 RSA_EN會(huì)導(dǎo)致 FSBL 無(wú)法對(duì)后續(xù) Partition 做認(rèn)證。

對(duì)應(yīng) Error Log
======= In Stage 3, Partition No:1 =======
UnEncrypted data Length: 0x49E1
Data word offset: 0x49E1
Total Data word length: 0x4DA0
Destination Load Address: 0xFFDC0000
Execution Address: 0xFFDC8C68
Data word offset: 0x7A70
Partition Attributes: 0x883E
QSPI Reading Src 0x31180, Dest FFFDC490, Length EC0
.QSPI Reading Src 0x1E9C0, Dest FFDC0000, Length 127C0
.Authentication Enabled
Auth: Partition Offset FFDC0000, PartitionLen 13680, AcOffset FFFDC490, HashLen 30
XFsbl_SpkVer: XFSBL_ERROR_SPK_RSA_DECRYPT
Partition 1 Load Failed, 0x2F

RSA 認(rèn)證成功后 JTAG 無(wú)法使用，無(wú)法用 SDK 燒錄Flash

當(dāng)系統(tǒng)從經(jīng)過(guò)RSA認(rèn)證的鏡像啟動(dòng)成功，JTAG 是可以使用的，但是默認(rèn)并沒(méi)有打開(kāi)，這導(dǎo)致了一些不方便，比如使用 SDK 燒錄其他鏡像，或者用 SDK 進(jìn)行程序調(diào)試等。

通過(guò)在 FSBL 中增加AR 68391中提示的代碼，就可以打開(kāi) JTAG。一般將它放在 hook before handoff 就可以。

Xil_Out32(0xffca0038,0x3F);
Xil_Out32(0xffca003C,0xFF);
Xil_Out32(0xffca0030,0x3);
Xil_Out32(0xFF5E00B0,0x01002002);
Xil_Out32(0xFF5E0240,0x0);
Xil_Out32(0xFFCA3000,0x1);

注意：由于這些代碼修改 CSU 寄存器，需要運(yùn)行在 EL3 等級(jí)，所以如果放在 U-boot 或者 Linux 代碼中是不工作的。

用燒寫(xiě) RSA Key 的程序不能燒錄 Blackkey

libSKey 用于燒寫(xiě) MPSoC 的 eFUSE key，有兩個(gè)常用程序，分別是 xilskey_efuseps_zynqmpe_example 和 xilskey_puf_registration。后者能燒寫(xiě) Blackkey 和 Helperdata。前者能燒寫(xiě) RSA PPK 和 Redkey 等除了 Blackkey 以外的情況，因?yàn)樗惶幚?helperdata。

啟動(dòng)后什么也沒(méi)顯示，改怎么調(diào)試？

如果已經(jīng)燒錄了 RSA_EN，但是鏡像認(rèn)證出錯(cuò)，芯片會(huì)關(guān)閉大部分 JTAG 通道，XSCT 無(wú)法掃描 JTAG 上的器件，也就無(wú)法進(jìn)一步debug。在這種情況下只有一個(gè)通道被留了下來(lái)協(xié)助調(diào)試，他就是 JTAG Error Status 寄存器。

1. 怎樣讀取 JTAG Error Status

請(qǐng)聯(lián)系 FAE 了解怎樣獲取 JTAG Error Status 信息，并提供參考資料號(hào)碼AR68515 。

2. 獲取 CSU Error Code

JTAG Error Status 是一個(gè) 121 位的狀態(tài)信息。根據(jù) AR68515 找出 CSU BootROM Errors (CSU_BR_ERR.ERR_TYPE)。

3. 分析錯(cuò)誤原因

UG1085 Table 11-8 和 11-9 描述了它的意義。找到對(duì)應(yīng)的錯(cuò)誤模式，再修正錯(cuò)誤。

不同的安全啟動(dòng)模式能不能混用？

安全啟動(dòng)模式有很多中，比如只用 RSA，只用 AES，或同時(shí)使用 RSA 和 AES；RSA 和 AES 的情況下，還有使用 eFUSE key, BBRAM Key, Red Key, Gray Key, Black Key 等情況。

以上各種組合，在一次 POR 的情況下，只能保持使用同一種組合。POR 是 Power on Reset，相當(dāng)于系統(tǒng)完全斷電，或 PS_POR_b 信號(hào)拉低，不包含內(nèi)部通過(guò)寄存器重啟的情況。

• 由于 Multiboot 使用內(nèi)部寄存器重啟機(jī)制，所以如果使用 Multiboot，需要保證所有的鏡像使用相同的安全啟動(dòng)模式。
• 如果 U-boot 需要加載一些經(jīng)過(guò) RSA 或 AES 加密的鏡像，也需要保證加載的鏡像與啟動(dòng)鏡像使用同樣的安全啟動(dòng)模式。

一個(gè)完備的安全啟動(dòng)還需要考慮哪些因素

怎樣保證從頭到尾的安全啟動(dòng)

本文描述的只是安全啟動(dòng)的最簡(jiǎn)單的幾種方式。如果需要考慮其他方式，比如 Linux 文件系統(tǒng)需要直接存在 Flash 中，要保證黑客無(wú)法攻擊、修改 Flash 上的文件保證系統(tǒng)安全就會(huì)更難一些。一只雞蛋只要有一條裂縫，它就會(huì)變臭的。

怎樣安全升級(jí)

遠(yuǎn)程系統(tǒng)升級(jí)是一個(gè)很常見(jiàn)的需求，即使沒(méi)有安全啟動(dòng)的需求，也可能考慮遠(yuǎn)程升級(jí)和升級(jí)失敗的恢復(fù)。在需要安全啟動(dòng)的狀況下，需要保證傳輸通道可靠安全、傳輸內(nèi)容不能包含私鑰，用帶安全啟動(dòng)功能的 Boot.bin 燒錄到 Flash 上，做好燒錄失敗的恢復(fù)機(jī)制即可。

怎樣安全生產(chǎn)

生產(chǎn)主要需要考慮兩方面內(nèi)容，一是生產(chǎn)廠(chǎng)商是否可以信任，哪些內(nèi)容可以交給廠(chǎng)商，密鑰泄露的風(fēng)險(xiǎn)有多大；二是生產(chǎn)效率，怎樣以更快的速度、更方便的流程，將密鑰燒入 eFUSE，將加密鏡像燒如 Flash。

六、總結(jié)

?本文從講解常用攻擊方法入手，隨后介紹了 MPSoC 如何防御以上講到的常用攻擊手段，怎樣規(guī)劃安全啟動(dòng)，加上實(shí)際的操作指南，并附上常見(jiàn)問(wèn)題及解釋。希望你看完后能了解到，堵上系統(tǒng)中的安全隱患是有必要的，以及在 MPSoC 上使用安全啟動(dòng)功能，使用成本是很低的，只需要通過(guò)一些簡(jiǎn)單的學(xué)習(xí)實(shí)驗(yàn)，就可以讓你的系統(tǒng)更加安全可靠。

七、參考文檔

1. UG1085: MPSoC Technical Reference Manual
2. UG1209: Zynq UltraScale+ MPSoC: Embedded Design Tutorial
   • Ch.5 -> Secure Boot Sequence
3. UG1137: Zynq UltraScale+ MPSoC Software Developer Guide
   • Ch.7 -> Boot Flow -> Secure Boot Flow
   • Ch.8 -> Boot Time Security
   • Ch.16 Bootgen Image Creation
   • Appx. I: XilSecure Library
   • Appx. J: XilSKey Library
4. Xapp1333: External Secure Storage Using the PUF
5. Wiki - Authentication and decryption at u-boot
6. Wiki - Solution ZynqMP PL Programming
7. XAPP1319: Programming BBRAM and eFUSEs

編輯：hfy