[参考译文] TDA4VM：FS 带未签名映像的 HS-TDA4VM 芯片

您好、Joshua、

需要对主引导加载程序映像、MCU R5 引导加载程序 (SBL 或 SPL) 和 TIFS 二进制文件进行签名。 即使在 GP 器件上也是如此、这些器件也需要在二进制文件前具有 x509 证书。

启动过程中涉及到很多映像、您正在讨论哪些二进制文件？

您使用什么引导加载程序和 HLOS？

此致

Suman

尊敬的 Suman：

感谢您的回复！ 目前、我们在 R5 上使用 tiboot3.bin + sysfw.itb 作为引导加载程序、将 RTOS 作为 HLOS、将 tispl + uboot 作为引导加载程序、并在 A72 上使用 Linux 作为 HLOS。

我注意到、如果我们使用 HS-HLOS FS 版本、则会启用安全启动、因此如果次级引导加载程序和 HLOS 未签名、这应该是正常的、对吧？

我的理解是 TI 安全启动可以保护次级引导加载程序、但对于 HLOS 来说不是这样、正确吗？

您好、Joshua、

感谢您的回复！ 目前、我们在 R5 上使用 tiboot3.bin + sysfw.itb 作为引导加载程序、将 RTOS 作为 HLOS、将 tispl + uboot 用作引导加载程序、并在 A72 上使用 Linux 作为 HLOS。

谢谢、因此您将 Linux SPL/U-Boot 用作引导加载程序元件。

我注意到、如果我们使用 HS-Bits FS 版本、则表示未启用安全启动、因此如果次级引导加载程序和 HLOS 未签名、这应该没问题、对吗？

TIFS 二进制文件在 HS-TIFS 上使用 TI 密钥进行签名和加密 FS、此二进制文件会在引导过程中执行身份验证和解密过程。 除此之外、所有其他已签名的二进制文件都 使用客户密钥（或 ROM 生成密钥）进行签名、但 HS-ROM FS 器件不会熔断客户密钥。

Linux SDK 和 RTOS SDK 遵循与 HS-SDK 的映像略有不同的模型 FS。 RTOS SBL 将使用 ROM 生成的密钥对映像进行签名、而 Linux SDK 则使用客户密钥（SDK 上的 TI 虚拟密钥）对其进行签名。

我的理解是 TI 安全启动可以保护次级引导加载程序、但不能保护 HLOS、它是否正确？

没错。 也就是说、我们的 U-Boot 代码现在以统一的方式为 GP、HS-SE FS 和 HS-SE 器件编写、而引导加载程序代码会进行 DEVICE_TYPE 检测、并忽略通常与 HS-SE 映像关联/所需的证书。

这是为了能够像在最终产品中那样使用已签名映像、但仍能在开发 FS 电路板上以相同的方式继续使用这些映像。

在 HS-SE 器件上正确的 Linux 引导需要使用一个由内核映像和 DTB 组成的有符号时基故障映像。 您可以继续在 HS-Dtb 上使用未签名的 Linux 内核映像和 FS、与在 GP 器件上使用的情况一样。

此致

Suman

您好、Suman、

您能否详细介绍一下已签名的贴合图像？ 是否必须用于 HS-SE 器件？ 这是否意味着有符号的时基故障映像可以保护内核和 DTB、但不能保护 rootfs？

谢谢、

Joshua

嗨、Suman

感谢您的解释。

这是一个仔细检查和 结论 ,因为我想避免任何错过的理解。

如果客户希望使用 HS-BitLocker FS 器件在没有未签名映像的情况下进行开发

(1)  sysfw.itb ->您必须使用带有 TI 虚拟密钥的“已签名“SYS FW、这是 TI 加密的、而不是 CUTOMERIZED 密钥、它已经在 SDK 中。

(2) tiboot3.bin ->未签名映像在客户密钥编程之前正常。

(3) tispl.bin -> 未签名的映像在客户密钥编程之前正常。

(4)  在客户密钥编程之前、u-boot.img ->无符号映像正常。

(5) 内核+ DTB (FIT image)-> 在客户密钥编程之前、无符号映像正常。

(6) rootfs -> 无符号图像合适。

将 HS-EMGD FS 器件与签名的密钥一起使用。

(1)  sysfw.itb ->您必须使用带有 TI 虚拟密钥的“已签名“SYS FW、这是 TI 加密的、而不是 CUTOMERIZED 密钥、它已经在 SDK 中。

(2) tiboot3.bin -> 需要客户签名的映像

(3) tispl.bin ->需要客户签名的映像

(4) u-boot.img -> 无符号映像也可以接受、因为它 对于 GP、HS-SE FS 和 HS-SE 器件的方式是一致的

(5) 内核+ dtb (FIT image)->需要客户签名的映像

(6) rootfs -> 无符号图像合适。  

谢谢你。

Gibbs

嗨、Suman

感谢您的答复、因为我不是很熟悉的安全设备、所以我需要尽可能详细地检查。

一些澄清、

TI Dummy Key is used as a Customer SMPK Key. The TIFS binaries get delivered as signed and encrypted by TI MPK and TI MEK, which are different. So, you shouldn't be needing to "sign" the SYSFW binary with TI Dummy Key.

如果我们使用 HS-MPK 器件、则必须使用“由 TI FS 和 TI MEK“签名和加密 TIFS 二进制文件 (sysfw.itb)
如果我们使用 GP 器件、则不得使用“由 TI MPK 和 TI MEK“ TIFS 二进制文件签名和加密 (sysfw.itb)

即使是 GP 或 HS-EMA FS 器件、sysfw.itb 也由 TI 提供（生成）、因此客户无需关心此二进制文件  

tiboot3.bin image should always have a x509 Certificate. So you can use either the ROM degenerate key or the Customer Private Key on HS-FS. The Customer Private Key is needed to sign on HS-SE.

如果我们使用 HS-Key FS 器件、则必须在签名客户私钥的情况下使用 tiboot3.bin。
如果我们使用 GP 器件、则必须在未签名客户私钥的情况下使用 tiboot3.bin。

我们的 FS 将同时生成已签名 (HS-SDK) 和未签名 (GP) tiboot3.bin、这取决于客户 是否已在源代码中添加补丁“客户私钥“。 SDK 中的默认密钥为“TI 虚拟密钥“

FIT image is mandatory for using on HS-SE, and usage of a FIT image for GP or HS-FS is optional

如果客户计划将来使用 HS-Image 器件、则应尝试研究如何使用 FS 图像。
甚至可以“无签名“安装映像、该映像也可以在 FS 器件上运行

如果我说的是错误的、请纠正我。

非常感谢

Gibbs

嗨、Suman

我有点困惑这个术语“ROM degenerate Key“、您能给我们一些相关信息吗？

参考此页面、

https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/10_00_00_08/exports/docs/linux/Foundational_Components /U-Boot/UG-General-Info.html？highlight=sysfw%20itb

尽管讨论了 FIT 映像、我们的 GP FS 仍将构建 3 种类型的二进制文件、其中包括 SDK/HS-SE/HS-SE

如果客户使用的 FS 是不带“客户私钥“的 HS-器 件、则可以直接使用 FS 二进制构建。

如果他们的器件已经成为具有“客户私钥“的 HS-SE 器件、则可以直接使用 HS-SE 二进制构建。

这是最简单的方法、我的回答是正确的吗？

谢谢你。

Gibbs

嗨、Suman

如果我们需要使用 FS 启动 HS-SDK 器件（5B 或 5C 器件）、以下几点理解正确：

我们可以使用所有 GP 映像 但不同之处 对于必须更换的以下两项：

 适用于 5B FS：

1. 更换 sysfw-j721e-gp-evm.itb
   ➜Ω sysfw-j721e_sr1_1-hs-fs-evm.itb

2. 更换 tiboot3-j721e-gp-evm.bin
   ➜Ω tiboot3-j721e-sr1_1-hs-fs-evm.bin

所有其他映像（例如，，，tispl.binu-boot.imgkernel、dtb、rootfs、 可以保留为 GP 版本。

 适用于 5C FS：

1. 更换 sysfw-j721e_gp-evm.itb
   ➜Ω sysfw-j721e_sr2_0-hs-fs-evm.itb

2. 更换 tiboot3-j721e-gp-evm.bin
   ➜Ω tiboot3-j721e-sr2_0-hs-fs-evm.bin

同样、所有其他映像可保留为 GP 版本。

请确认：
在 HS-引导 器件上、与 FS GP 引导相比、唯一需要的区别是使用适当的 tiboot3FS 和 sysfw而所有其他映像（例如，，，内核，tispl.binu-boot.imgdtb、 rootfs) 可以与 GP 版本相同吗？

BR

Jay

对 Jay 的评论

5B/5C 的含义是什么、

嗨、Suman  

感谢您的详细说明。

我们想进一步确认我们的用例、其中包括从 GP 过渡到 FS 器件、以进行早期电路板启动和功能验证。

我们的设置和目标

• 我们已经有了 客户电路板 使用进行验证 GP 器件 。

• 现在、我们计划要实现 将 GP 器件替换为 5°C FS 器件 在上 同一块电路板 。

• 目标是 使用现有的 FS 映像（sysfw 和 tiboot3 除外）引导 GP 器件 进行早期功能测试。

动机

• 在这个阶段、我们已经有了 尚未使用 Keywriter 对器件进行编程 、因此设备仍在中  FS 状态 。

• 我们希望重复使用 GP 映像 引导并验证关键硬件接口  。

• 功能验证完成后、我们将继续 使用 Keywriter 对器件进行编程 、从而有效地将其转换为 FS 状态。

• 在最后一个阶段、我们将使用完全重新测试 已签名的映像 安全启动流程来启用引导加载程序。

摘要

我们的问题是、这是否可以接受 早期 FS 启动 临时使用 GP 签名的映像（tiboot3 和 sysfw 除外） 。

感谢您的确认和指导。

BR

Jay

尊敬的 Jay：

我们想进一步确认我们的用例、其中包括从 GP 转换到 FS 器件、以实现早期电路板启动和功能验证。

感谢您的背景。

您的客户使用哪个 Linux SDK？ U-Boot 在开发过程中不断发展、同时启用了对 HS-YAML 的引导支持、并使用 FS 和 BinMan 生成 sysfw.itb 文件。

功能验证完成后、我们将继续 使用 Keywriter 对器件进行编程 、有效地将其转换为 HS-BIOS FS 状态。

一旦 KeyWriter 运行、这会将器件转换为 HS-SE。

我们的问题是、它是否可以接受 早期 FS 启动 临时使用 GP 签名的映像（tiboot3 和 sysfw 除外） .

我建议遵循与 TI SDK 相同的流程、因为这是标准推荐方法。  

但我知道您需要在电路板启动早期阶段尝试此操作。 如果遇到任何问题、我建议您打开新主题、我没有 FS 用于自行检查/验证的 HS-EVM 板。

此致

Suman