ARMv7安全引導的過程

對于安全引導功能的實現(xiàn)和驗證過程各家芯片公司的方案都不一樣，這是由該芯片的啟動流程以及啟動所需鏡像文件來決定的，但都會遵循鏈式驗簽啟動的原則。

ARMv7架構(gòu)并沒有使用ATF，系統(tǒng)的啟動流程與以前一樣使用BootLoader來引導Linux內(nèi)核和TEE
OS。安全引導的啟動流程如圖下所示。

安全引導的啟動流程

系統(tǒng)啟動過程使用鏈式驗簽的方式進行引導，其中任何一環(huán)驗簽失敗都會導致系統(tǒng)啟動失敗，為防止通過替換ramdisk來修改根文件系統(tǒng)中的內(nèi)容，一般將ramdisk與Linux內(nèi)核打包在同一個鏡像文件中，而且該鏡像文件需要待驗簽通過后才可被使用。

簽名信息一般是對鏡像文件的內(nèi)容進行哈希計算獲取摘要后再對該摘要使用RSA私鑰進行電子簽名來獲得，驗證時同樣會計算需要被引導的鏡像文件的摘要，然后使用該摘要、簽名信息以及RSA公鑰進行RSA算法的驗證。這個就是對稱的過程，加密簽名，驗簽解密。

ARMv8安全引導的過程

ARMv8架構(gòu)之后ARM提供了ATF，BootLoader、TEE鏡像文件、Linux內(nèi)核鏡像文件、recovery鏡像文件都是由ATF來進行引導和加載而不是由ChipRom來完成的。

ChipRom只會去驗證ATF中bl1的合法性，后續(xù)引導過程同樣也是按照鏈式驗簽的方式進行，符合TBBR規(guī)范。讀者可使用git命令從gitHub上獲取ATF的所有源代在ARMv8架構(gòu)中整個安全引導的流程如圖下所示。

ARMv8的Secure Boot流程

ARMv8架構(gòu)中引入了ATF，同時在ATF中提供了安全引導的功能，BootLoader鏡像、Linux內(nèi)核、recovery鏡像和TEE OS鏡像文件的簽名方式都由ATF決定。當然開發(fā)者也可以對ATF進行定制化，修改ATF中的驗簽過程，但是修改后的驗簽方案需要符合TBBR規(guī)范。

此時ATF不要和BL31搞混了哦。ATF是一個整個啟動鏈路。