[参考译文] TDA4VH-Q1：如何对诸如 tiboot3、tispl (ATF optee uboot-SPL)、uboot、ftimage (Linux)等映像签名

嗨、hongyao.jin 、

在生成签名的 tispl,tiboot3.bin,uboot.img 图像构建基础设施时使用  k3-j784s4-binman.dtsi 配置文件。 默认情况下、SDK 中用于对映像签名的根信任 密钥为 custMpk.pem、该密钥是您需要使用 YOU 密钥而不是 TI 虚拟密钥。

有关内核 fidimage 生成的 说明、请参阅 SDK 文档。

此致
Diwakar

你(们)好

在 SPL 模式下、可以成功验证所有系统固件、系统正常启动。

然后我们尝试在 hs-se 中调试 SBL、我们应该如何签署 tiboot3.bin、tifs.bin、combined.appimage、 是否有任何文档可供参考？

顺便说一下、我们似乎没有在 SPL 模式下对 sysfw.itd 进行签名、因此我们是否需要在 SBL 模式下对 tifs.bin 执行一些额外操作

嗨、hongyao 、

[报价 userid="533595" url="~/support/processors-group/processors/f/processors-forum/1445392/tda4vh-q1-how-to-sign-an-image-such-as-tiboot3-tispl-atf-optee-uboot-spl-uboot-fitimage-linux/5550837 #5550837"]然后我们尝试在 hs-se 中调试 SBL、我们应该如何签署 tiboot3.bin、tifs.bin、combined.appimage、 是否有任何文档可供参考？

当您说您要调试时、您是要启用 JTAG 还是要验证 SBL 引导流程？

如果您希望仅使用 SBL 引导流程引导器件、建议查看 SDK 文档。

[报价 userid="533595" url="~/support/processors-group/processors/f/processors-forum/1445392/tda4vh-q1-how-to-sign-an-image-such-as-tiboot3-tispl-atf-optee-uboot-spl-uboot-fitimage-linux/5550837 #5550837"]顺便说一下、我们似乎没有在 SPL 模式下签署 sysfw.itd、所以我们是否需要在 SBL 模式下对 tifs.bin 执行一些额外操作

Binman 使用已签名的 TIFS 内部证书、并 使用根信任密钥(SMPK、BMPK)生成外部证书、  

有关 TIFS 的内部证书和加密二进制文件、请参阅 /board-support/prebuilt-images/ti-sysfw

• ti-fs-firmware-j784s4-hs-cert.bin ->与 TI MPK 签署的内部 CETCATE
• ti-fs-firmware-j784s4-hs-enc.bin ->使用 TI MEK 签名的加密二进制文件

此致
Diwakar

嗨、hongyao 、

我跳过了、您使用 的是正确的 ATF 编译、如果 ATF 编译的器件错误可能导致 SEC 代理配置错误。

[报价 userid="533595" url="~/support/processors-group/processors/f/processors-forum/1445392/tda4vh-q1-how-to-sign-an-image-such-as-tiboot3-tispl-atf-optee-uboot-spl-uboot-fitimage-linux/5553529 #5553529"]

我们希望 验证 SBL 引导流程、现在系统可以正常引导、但 ATF 似乎有一些错误消息

[报价]

 

此致
Diwakar

你(们)好

我们解决了 ATF 错误的问题、因为 tiboot3中的日志太多。

现在我们的系统已经成功地启动了签名,我们想尝试签名和加密接下来,我们可以参考哪些文档?

嗨、hongyao 、

BINMAN 的当前实现在脚本中不支持对二进制进行加密。 您可以使用 SBL x509CertificateGen.sh 脚本获取经过加密+签名的二进制文件。

请参阅一节 "2.2对系统映像签名和加密"  。

尽管 建议不要在引导流程中使用加密的二进制文件,因为它会增加引导过程中的额外时间。

此致
Diwakar

你(们)好

我们似乎已经在 SBL 模式下成功加密了 tiboot3和 combined.appimage、但这有点奇怪。 如何验证我们是否实施了加密？  我们发现、系统可以在不加密的情况下引导、因此加密时没有区别

你(们)好  

[报价 userid="533595" url="~/support/processors-group/processors/f/processors-forum/1445392/tda4vh-q1-how-to-sign-an-image-such-as-tiboot3-tispl-atf-optee-uboot-spl-uboot-fitimage-linux/5557855 #5557855"]我们似乎在 SBL 模式下成功加密了 tiboot3和 combined.appimage、但这有点奇怪。 如何验证我们是否实施了加密？  我们发现系统可以在不加密的情况下启动、因此加密时没有区别[/QUOT]

从日志中、您将无法查看加密+已签名映像是否经过身份验证、还是只是已签名映像、流将保持不变。

使用加密映像不会在引导流程中增加额外的处理时间、其他也不会增加。

肯定是这样  

此致
Diwakar

你(们)好

我们发现、在 SBL 和 SPL 模式下、combined.appimage 和 tisp 的检查模式。 纸盒不同。 在 SPL 中、tispl.bin 不会签名、而 ATF、OPTEE、DM 和 u-boot-spl 在引导期间签名和检查。

然而、在 SBL 中、combined.appimage 必须是签名、并且代码看起来仅用于检查 combined.appimage 的签名。

为什么会出现这样的差异、如果我们要检查 SBL 中 ATF、OPTEE、U-BOOT-SPL 等的签名、我们应该怎么做

[报价 userid="533595" url="~/support/processors-group/processors/f/processors-forum/1445392/tda4vh-q1-how-to-sign-an-image-such-as-tiboot3-tispl-atf-optee-uboot-spl-uboot-fitimage-linux/5558933 #5558933"]

我们发现、在 SBL 和 SPL 模式下、combined.appimage 和 tisp 的检查模式。 纸盒不同。 在 SPL 中、tispl.bin 不会签名、而 ATF、OPTEE、DM 和 u-boot-spl 在引导期间签名和检查。

然而、在 SBL 中、combined.appimage 必须是签名、并且代码看起来仅用于检查 combined.appimage 的签名。

为什么会出现这样的差异、如果我们要检查 SBL 中 ATF、OPTEE、U-BOOT-SPL 等的签名、我们应该怎么做

[报价]

这是在 SBL 中的设计、我们正在对整个组合的应用映像进行身份验证、然后 SBL 将解析应用映像的标头以在不同位置加载它。

目前没有支持  在 SBL 中单独验证映像,也没有计划在不久的将来添加此内容。

此致
Diwakar