转载:https://cloud.tencent.com/developer/article/1043659
一个移植了TEEOS的Android手机系统启动流程如下:
系统启动流程如图所示,具体为:
①系统上电,PC指针指向芯片内部BOOT ROM地址并执行。
②BOOT ROM从外部存储设备加载、验证preloader并跳转执行。
③preloader从外部存储加载(验证) ATF(ARM可信固件)、TEE OS、LK,并跳转到ATF执行。
④ATF跳转到TEE OS执行初始化,再返回ATF。
⑤ATF跳转到LK执行。
⑥LK加载运行Android linux kernel。
⑦系统加载Modem。
BOOT ROM:固化在CPU芯片内部ROM中,上电cpu pc就指向这段地址并开始运行。
Preloader: 手机出厂前由手机厂商烧写至cpu芯片外部存储器(如emmc)中,并由BOOT ROM加载至内存中执行。
Lk: 可看作一个第二阶段的bootloader,支持多种启动模式(fastboot meta normal等等),并加载bootimage执行。
TEE: 包含ATF和TEE OS两部分,共同构建安全执行环境。
Boot: Android Kernel。
只有理解了上述启动流程,我们可以更好的进行安全启动设计!
Google有如下要求:
验证启动功能旨在保证设备软件(从硬件信任根直到系统分区)的完整 性。在启动过程中,无论是在每个阶段,都会在进入下一个阶段之前先验证下一个阶段的完整性和真实性。 当用户对软件进行了不应进行的更改时,可以使用该功能向他们发出警告,比如当用户获得一台二手设备后告知他们软件经受了不应进行的更改。此外,该功能还可以提供进行远程认证时使用的其他设备完整性信号。该功能再加上加密功能以及可信执行环境 (TEE) 信任根绑定功能,三者共同为用户数据添加了另一道防范恶意系统软件的保护屏障。如果在任意阶段验证失败,用户都会收到醒目的通知。 目前基于TEE的系统与防范恶意系统软件保护之间,看似底层与上层相差甚远,各位看了上述Google的描述,是不是觉得可以产生结合,形成特色的安全解决方案了呢?