This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] AM6442:在处理之前验证时基故障图像

Guru**** 2380860 points
Other Parts Discussed in Thread: AM6442
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1500788/am6442-validating-a-fit-image-prior-to-processing

主题:AM6442中讨论的其他器件

工具/软件:

在我读取 R5 SPL/A53 SPL 代码时、只会在处理前检查 FIT 图像标头是否具有有效的魔术字段;一旦处理开始、就无法停止。

我的用例是尝试防止由 FIT 加载的其中一个映像中出现 eMMC 读取错误。 现在、所有内容都经过签名检查、并且配置已签名、因此不会发生任何混合匹配安全攻击-但如果其中一项签名检查失败、我无法看到如何"覆盖"并从回退扇区重新读取拟合映像。

我注意到 IMX 器件支持将整个 FIT 图像包装在证书中、这允许进行预加载检查-那么 TI 是否愿意考虑此类更改?

此致、

David

PS 我们在 Yocto scarthgap 分支上使用 SDK 10

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、David:
    在当前的 Linux SDK 中、每个 SPL/u-boot 二进制文件都单独签名并打包到 FIT 映像中、然后由 Bootrom 或 SYSFW/TIFS 进行验证、其中仅包含软件组件(二进制 blob、dtb…) 合法签名的将在从硬件复位开始锚定的硬件强制信任根的扩展安全启动流程期间通过验证过程。

    以下函数是 SYSFW/TIFS 单独进行 x.509签名验证的核心函数
    https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/arch/arm/mach-k3/security.c?h=11.00.10#n104

    此致、
    - Hong

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Hong Hong:

    我们担心的是、如果引导介质上的其中一个已签名的映像损坏(我们当前使用 eMMC)、则可能会导致引导失败。

    在这种情况下,我们认为 tispl 加载可能在 ATF 和 OPTEE 上成功(例如),然后在尝试加载 A53-SPL 时失败-在这种情况下,您显示的代码将调用'hang ()',我们怀疑它的作用与它所说的完全相同。

    我们要寻找的是在加载组件之前检查整个匹配图像的一种方法;这样、如果"主"版本已损坏、我们可以尝试使用 tispl 的另一个位置。 (当然、相同的过程也适用于 u-boot.img)

    我承认、另一种策略是在加载确实挂起时使用看门狗计时器重新启动引导过程-但我们在 am6442芯片中找不到任何允许我们设置"用户标志"的寄存器、以便我们可以判断看门狗是否重新启动、以及上一次引导必须达到什么状态。 (从我在看门狗上读取的所有内容来看、我们可以看到的唯一"实例"是"热重启"、这并不是特别有用)

    此致、

    David

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、David:
    一旦在单独签名的二进制 blob 上的当前 x.509签名验证失败、 我认为可以自定义代码以执行必要操作、即从备份位置重新加载/验证备份签名的二进制 blob。
    此致、
    - Hong