加密​FIT Secure Boot1、目标​ 在RK3566 Linux 5.10平台 上完成FIT Secure Boot开发与验证使设备只能启动签名正确的启动链镜像未签名或被篡改的镜像不能正常启动。1、FIT路线Rockchip Linux Secure Boot指南明确给出RK3588 / RK356XKernel 检验方式FIT内核版本5.10所以对RK3566来说应走RK3566 Linux 5.10 FIT Secure Boot而不是老平台常见的AVB vbmeta trust.img2、FIT和Base Secure Boot的关系文档说明Linux Secure Boot可分成三部分Base Secure BootAVB / FITDM-V如果平台使用FIT方案可以跳过单独的Base Secure Boot操作因为FIT已经集成了Base Secure Boot。所以对RK3566而言开发时不要再按“先单独做Base Secure Boot再做FIT”的思路拆开理解。3、OTP​OTP和Secure Boot for U-Boot next-dev相关文档都说明RK3566属于OTP平台。OTP用于保存Public Key Hash等安全信息且是不可逆写入。这意味着正式启用前必须先做好联调私钥必须妥善保存--burn-key-hash只能在最终确认无误后使用4、Secure Boot先用一句话解释FIT Secure Boot主要保护启动链不是默认保护整个rootfs。Rockchip Linux Secure Boot指南给出的Linux启动安全链路是BootRomLoader / SPLU-BootBoot / Recovery如果要进一步保护System / rootfs再走DM-V。所以本次RK3566 FIT Secure Boot的直接保护对象主要是Loader / SPLuboot.imgboot.imgrecovery.img可选而不是自动保护rootfs.imgoem.imguserdata.img如果以后要连rootfs一起保护要继续上DM-V分区加密。2、准备工作1、软件与环境建议准备u-boot/rkbin/顶层build.shU-Boot目录下的make.sh串口日志工具Windows端RKDevTool / AndroidTool2、文件和目录角色这次开发里最容易混淆的是这些文件u-boot/boot.img在签名链里这往往是真正被重新签名后的boot镜像kernel/boot.img可能是源码树里的boot镜像输入源output/update/Image/boot.img可能只是一个软链接并不一定代表它就是最新signed产物u-boot/uboot.img这是FIT下的U-Boot主镜像trust已经并入其中rk356x_spl_loader_v1.xx.xxx.bin这是新生成的SPL/loader文件很多情况下要拿它去替代老的MiniLoaderAll.bin3、开发流程1、生成FIT签名密钥FIT 文档说明FIT Keys 与 Base Secure Boot Keys 是同一套密钥固定文件名必须是keys/dev.keykeys/dev.pubkeykeys/dev.crt名字不能改否则打包失败。本次实际操作为cd u-boot mkdir -p keys touch ~/.rnd ../rkbin/tools/rk_sign_tool kk --bits 2048 --out . mv private_key.pem keys/dev.key mv public_key.pem keys/dev.pubkey openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt这里有一个实际踩坑点rk_sign_tool生成的文件名不是文档里的privateKey.pem实测发现sign_tool ver 1.4实际生成的是private_key.pempublic_key.pem而不是很多文档和旧经验里写的privateKey.pempublicKey.pem2、打开U-Boot FIT签名配置文档给出的 FIT 必选配置是CONFIG_FIT_SIGNATUREyCONFIG_SPL_FIT_SIGNATUREy可选配置CONFIG_FIT_ROLLBACK_PROTECTyCONFIG_SPL_FIT_ROLLBACK_PROTECTy本次实际启用后.config中已看到CONFIG_FITyCONFIG_FIT_SIGNATUREyCONFIG_SPL_FIT_SIGNATUREyCONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORTyCONFIG_FIT_IMAGE_POST_PROCESSyCONFIG_FIT_HW_CRYPTOy3、保存配置这是本次开发过程中最重要的坑之一。make menuconfig改的是当前.config但make.sh会重新加载configs/rk3568_defconfig所以如果只做make menuconfig make savedefconfig但不把defconfig覆盖回configs/rk3568_defconfig下一次执行./make.sh rk3568 ...时配置会被默认defconfig覆盖掉结果又变成Image(no-signed, version0)。这个问题在本次开发中已经实测出现。正确做法在u-boot/下执行make rk3568_defconfig make menuconfig make savedefconfig cp configs/rk3568_defconfig configs/rk3568_defconfig.bak cp defconfig configs/rk3568_defconfig文档也明确建议先menuconfig再savedefconfig更新原defconfig避免依赖不一致。4、执行FIT签名链顶层build.sh生成 SDK 整体镜像、打包系统u-boot/make.sh执行 FIT 签名链所以--spl-new --boot_img --burn-key-hash这些 FIT 参数应当给u-boot/make.sh而不是顶层build.sh。测试有实际遇到脚本找gcc-linaro-6.3.1-2017.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc但 SDK 实际有的是gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc​ 所以脚本一开始找不到编译器。​ 给make.sh期望的位置补一层兼容目录或软链接让它能找到aarch64-linux-gnu-gcc这一套名字即可。5、执行签名文档说明u-boot/make.sh在编译签名时会同时对boot.imgrecovery.imgloader.binuboot.img进行签名必须指定一个真实可签名的FIT格式boot.img。联调阶段先不要写OTPcd u-boot sudo ./make.sh rk3568 --spl-new --boot_img /media/work/work/rk_sdk/rk_linux_sdk/kernel/boot.img成功时实际看到Signature check OKImage(signed, version0): uboot.img ...Image(signed, version0): boot.img ...Image(signed): rk356x_spl_loader_v1.19.113.bin ...这就说明签名链已经跑通。6、正式写入OTP Key Hash确认联调成功后再执行正式版cd u-boot sudo ./make.sh rk3568 --spl-new --boot_img /media/work/work/rk_sdk/rk_linux_sdk/kernel/boot.img --burn-key-hash文档说明--burn-key-hash会要求SPL阶段把公钥hash写入OTP / eFuse成功时会出现RSA: Write key hash successfully.