Open quinnwencn opened 4 months ago
在现有的升级方案中，Aktualizr在每次更新后，都会对uboot的环境变量进行修改，告诉uboot将从那个commit hash中拉起rootfs，以实现rootfs更新的目的。这就要求uboot的环境变量具有可修改的属性，在没有开启Secure boot之前，这个属性是支持的。
在启动时，uboot中存储了启动标志和回滚标志，在启动到Ramdisk时，会读取uboot的这两个环境变量，决定从哪个rootfs启动。在使用Aktualizr更新时，除了更新rootfs外，还需要将启动标志和回滚标志进行更新，以便下一次从最新的rootfs启动。在引入secure boot之前，这个流程是正常工作的。
在LS1043使能Secure boot后，根据NXP对于Secure Boot的描述，uboot整体（包括环境变量）、Kernel和Ramdisk都将要在编译期间进行签名，签名后如果需要更改，那就需要重新签名并刷写，这显然与现存Aktualizr升级方案不兼容。
FOTA的核心诉求是提供对uboot环境变量的访问和修改，而Secure Boot的核心功能就是避免未授权的修改，保护固件的完整性。如果不增加额外处理，这个诉求是无法得到满足的。从Secure Boot的角度出发，Uboot必须不可变更，由签名保护Uboot的完整性，如果要在不破坏Uboot完整性的基础上去修改Uboot的环境变量，那么环境变量就不能存储在Uboot被签名的区域中。
为了不破坏Uboot的完整性，一个可行的方案是将Aktualizr使用的Uboot环境变量从Uboot镜像中分离出来，采用其他方式进行存储。
但是，分离出的环境变量需要满足两个条件：
Uboot能正常读取
不能被非法篡改
那么FOTA和Secure Boot无法兼容的问题就转移到了这部分分离的Uboot环境变量如何存储的问题上。目前的Proposal是：EMMC新建一个小分区，用于存储分离的Uboot环境变量，并对这片分区进行加密，只有Uboot和FOTA能正常解密，为了确保完整性，可以使用AEC-GCM进行加密存储。
TODO
1.背景
在现有的升级方案中，Aktualizr在每次更新后，都会对uboot的环境变量进行修改，告诉uboot将从那个commit hash中拉起rootfs，以实现rootfs更新的目的。这就要求uboot的环境变量具有可修改的属性，在没有开启Secure boot之前，这个属性是支持的。
在启动时，uboot中存储了启动标志和回滚标志，在启动到Ramdisk时，会读取uboot的这两个环境变量，决定从哪个rootfs启动。在使用Aktualizr更新时，除了更新rootfs外，还需要将启动标志和回滚标志进行更新，以便下一次从最新的rootfs启动。在引入secure boot之前，这个流程是正常工作的。
在LS1043使能Secure boot后，根据NXP对于Secure Boot的描述，uboot整体（包括环境变量）、Kernel和Ramdisk都将要在编译期间进行签名，签名后如果需要更改，那就需要重新签名并刷写，这显然与现存Aktualizr升级方案不兼容。
2. 解决方案
FOTA的核心诉求是提供对uboot环境变量的访问和修改，而Secure Boot的核心功能就是避免未授权的修改，保护固件的完整性。如果不增加额外处理，这个诉求是无法得到满足的。从Secure Boot的角度出发，Uboot必须不可变更，由签名保护Uboot的完整性，如果要在不破坏Uboot完整性的基础上去修改Uboot的环境变量，那么环境变量就不能存储在Uboot被签名的区域中。
2.1 分离Uboot的环境变量
为了不破坏Uboot的完整性，一个可行的方案是将Aktualizr使用的Uboot环境变量从Uboot镜像中分离出来，采用其他方式进行存储。
但是，分离出的环境变量需要满足两个条件：
Uboot能正常读取
不能被非法篡改
那么FOTA和Secure Boot无法兼容的问题就转移到了这部分分离的Uboot环境变量如何存储的问题上。目前的Proposal是：EMMC新建一个小分区，用于存储分离的Uboot环境变量，并对这片分区进行加密，只有Uboot和FOTA能正常解密，为了确保完整性，可以使用AEC-GCM进行加密存储。
3. 开发
TODO