2312976_zh-CN

Yes

S32G 上的 SYS_IMG KeyCatalog 已损坏

您好，

我使用的是 S32G2。安全启动已启用。IVT 正确定义了我在 M7 上的启动 BootManager、HSE_FW 的位置以及 SYS_IMG 在或非闪存中的位置。所有这些区域都在 IVT 中定义了备份。

我还在该区域末尾启用了 BootManager 签名。SMR 的定义是正确的。我设法启动了很多次。我还设法更新了 BootManager，并再次重新签名。这涉及到更新 SMR 和更新 SYS_IMG。还重新生成了 SYS_IMG 的备份，两者都写入了或非闪存中。

这一更新过程已经进行了多次。没有问题。

经过多次更新周期，我的 BootManager 已停止启动。SYS_IMAGE 通过了 hseVerifySysImageSrv 测试。根据 RM00301 HSE 固件手册，检查了或非闪存后，它的 4KB 标头似乎不错，小于 8 KB 的 " HSE 配置数据集 "，以及小于 32KB 的良好 " NVM 密钥存储数据集 "。

鉴于我的 BootManager 无法再启动，主板会在 1 秒钟后 RESET。重置 5 次后，它进入睡眠状态。

我如何知道问题是出在 HSE 不喜欢 SYS_IMG，还是 SYS_IMG 丢失了我的 BootManager 的 SMR，或者我的 BootManager 密钥与内容不匹配？

如前所述，hseGetSysImageSizeSrv 报告 HSE_SRV_RSP_OK 为正。

有办法离线分析 SYS_IMG 吗？我看到在 0x1000 处它有字节 " E1 E1 E1 " 之后有 4 个字节可能是计数器。在此之后，数据被编码，所以我不知道是否存在用于 BootManager 的 SMR 和密钥。

谢谢！

旧金山

Re: SYS_IMG KeyCatalog corrupted on S32G

您好，

感谢您的答复。 hseVerifySysImageSrv_t是成功的，因此可以确认 SYS-IMG 在某种程度上是正确的。

我所做的是：将错误的 SYS-IMG 保存在其他或非地址中。将 IVT 指向已知有效的 SYS-IMG。指向坏 SYS-IMG 的 hseVerifySysImageSrv_t 调用成功，因此确认该 SYS-IMG 已验证。但这并不能保证内容包括 SMR 或 BootManager 的密钥，对吗？

当 IVT 指向坏的 SYS-IMG 时，它不会验证我的 BootManager，而 BootManager 会以某种方式表明坏的 SYS-IMG 缺少 SMR。

是否有可能在运行时要求 HSE 加载坏的 SYS-IMG，然后使用 Hse_GetKeyInfo 来了解键是否存在？我知道如果键不存在，Hse_GetKeyInfo 会返回错误信息，因此这将告诉我在我的坏 SYS-IMG 中哪些键仍然可用。

是否有办法加载坏的 SYS-IMG，并调用 smrVerifyReq (HSE_SRV_ID_SMR_VERIFY)？这将告诉我，坏的 SYS-IMG 是否有我的 BootManager 的 SMR，或者它是否丢失了它。

谢谢！

旧金山

Re: SYS_IMG KeyCatalog corrupted on S32G

你好@nxg19026、

关于 SYS-IMG 的离线审查，没有检查加密内容的程序，它确实保存了所有非易失性信息，但在 HSE 外部无法访问。不过，您可以使用hseVerifySysImageSrv_t来仔细检查闪存中的 SYS-IMG 是否正确。

此外，按照HSE FW参考手册中提到的内容，如果SYS-IMG损坏，HSE会将设备RESET最多8次，然后再切换到串行模式进行恢复。

如果验证成功，请告诉我。

Re: SYS_IMG KeyCatalog corrupted on S32G

你好@nxg19026、

如果验证运行成功，说明 SYS-IMG 中的信息是正确的。重新加载运行时加载，不可能加载不同的 SYS-IMG，SYS-IMG 由 BootROM 加载，无法更改。

但是，正如我所提到的，如果SYS-IMG真的损坏了，芯片将无法启动，因此我看不到任何迹象表明SYS-IMG是问题所在。

您能否详细说明 BootManager 的具体功能和故障原因？

谢谢！

Re: SYS_IMG KeyCatalog corrupted on S32G

您好，

更多信息：我使用的是 HSE rev2.1_s32g2xx_hse_fw_0.1.1_2.22.0_pb230810 , premiun 版本有更多可用密钥。

HseNvmKeyCatalog 中的一个组有 20 个 hseKeyType_t HSE_KEY_TYPE_AES 密钥，每个密钥长度为 256。

在确认通过 Hse_VerifySysImg 进行的验证成功后，调查开始向另一个方向进行：

1) 我闪存了一个无签名的 BootManager，并告诉 IVT 我不需要签名。这样我就可以用新的调试功能来扩展 BootManager。

2) 我闪存了一个旧的、有效的 SYS-IMG .NET。我使用 Hse_GetKeyInfo 确认它有 BootManager 的密钥。

3) 我刷新了有问题的 SYS-IMG .NET。现在 Hse_GetKeyInfo 告诉我 BootManager 的密钥已不存在。

为了保存 SYS_IMG，我遵循了推荐的流程：hseGetSysImageSizeSrv，然后是 hsePublishSysImageSrv，然后使用闪存驱动程序保存到或非 Flash 中。

因此，"我的更新 "进程似乎写入了一组空键。我只能想象我是因为不小心调用了 hseFormatKeyCatalogsSrv_t (HSE_SRV_ID_FORMAT_KEY_CATALOGS)而丢失了它们。

可能是 hsePublishSysImageSrv 为另一个 MuInstance 获取了密钥？我已为 HSE_MU0_MASK 和 HSE_KEY_OWNER_CUST 定义了所有键值。据我所知，hsePublishSysImageSrv 会检索所有 hseMuMask_t 和所有 hseKeyGroupOwner_t 的所有密钥，对吗？

我的 BootManager 运行方式如下：

a) 需要 508 KB。签名在最后 4 KB 中。AppBL 将其指向 IVT。它由 SMR 启动。它的密钥类型为 HSE_KEY_TYPE_AES

b) 有 AppBL 备份。它使用相同的密钥，但 SMR 不同。

c) 通过通信，可将其更新到 AppBL 位置。请注意，AppBL 备份是存在的，以确保 A/B

d) 生成一个新密钥，并通过 targetKeyHandle 导入其插槽。计数器的值为 HSE_KF_MAX_KEY_COUNTER_VALUE。authKeyHandle 是 HSE_INVALID_KEY_HANDLE 签名在最后 4KB 被重写。

e) 重新生成 SMR

f) 调用 hseGetSysImageSizeSrv、hsePublishSysImageSrv 并写入 SYS_IMG

g) 它将二进制文件闪存到 Appbl-Backup 中，并执行相同的 e) 和 f)

这已经行之有效了很长时间，很多板。它只是一个密钥目录为空的板。

我们无法从 HSE 读取寄存器 GSR，因为电路板会重置，而且 PMIC 未初始化并进入休眠状态。我想这并不重要，因为我知道钥匙目录已经清空了。

谢谢。

旧金山

Re: SYS_IMG KeyCatalog corrupted on S32G

您好，

感谢您的回复。它给了我测试和重新分析的提示。

来自此评论"它会保存目录中的所有密钥以及 HSE 的所有非易失性配置。" -> 我测试过将 SYS_IMG 加载到可启动配置（即不使用 SecureBoot）并调用 Hse_GetKeyInfo。由于所有密钥都失败了，这证明密钥不存在。

你说在 SYS_IMG 中也存在易失性配置。是否可以通过询问 HSE 来了解存在哪些配置？这将有助于我了解哪些 SMR 仍在定义中。

为了进行测试，我尝试 hseSmrEntryErase 一个 SMR，我知道这个 SMR 从未定义过，但我得到了 HSE_SRV_RSP_OK。您能否确认，如果 SmrEntry 丢失或已被擦除，hseSmrEntryEraseSrv_t 是否会失败？

与 hseCrEntryEraseSrv_t 类似。似乎总是成功的，即使条目不存在。

如前所述，我们使用高级 HSE 固件，因为我们使用 32 个 SMR。

我还能从 SYS_IMG 中提取其他信息吗？例如，在偏移量 0x1004 处，我得到了 4 个字节，看起来像是 SysImage 发布时间的计数器。

"我想是多核" -> 你说得对，这是一个风险。因此，BootManager 是单核的，与 HSE 的交互也是单例的，以尽量减少这种风险。

从您的评论"其中一个程序覆盖了系统映像" -> 由于系统映像是有效的，这意味着它已经发布。否则或非闪存中会包含垃圾，对吗？

目前，我正在调查密钥被无意删除的可能性。或者通过格式化 KeyCatalog，或者通过 hseEraseKeySrv_t，使用 HSE_ ERASE_ ALL_NVM_
KEYS_ ON_MU_IF 或 HSE_ ERASE_KEYGROUP_ ON_MU_IF，不过我对此表示怀疑，因为 BootManager 没有任何实现该功能的函数。

谢谢！

旧金山

Re: SYS_IMG KeyCatalog corrupted on S32G

你好@nxg19026、

回答这个问题："可能是 hsePublishSysImageSrv 为另一个 MuInstance 获取了密钥？"在我看来，在您的应用程序（我猜想是多核应用程序）中，其中一个程序覆盖了 sysimage，这将导致图像没有有用的信息，而且"正确" 。

对于这个问题"，hsePublishSysImageSrv会检索所有 hseMuMask_t 和所有 hseKeyGroupOwner_t 的所有密钥，对吗？"它可以保存目录中的所有密钥以及 HSE 的所有非易失性配置。

根据描述，我只能得出这样的结论：有人未经授权要求发布 SYS-IMG，从而删除了你的密钥。另一种可能性很小，那就是芯片的硅片出了问题，导致 SYS-IMG 被覆盖，但这很难诊断。

根据目前的信息，我无法为您提供更多的支持，对此我深表歉意。

如果您有更多问题，请告诉我。

Re: SYS_IMG KeyCatalog corrupted on S32G

我们发现，尽管hseVerifySysImageSrv_t成功了，但 SYS_IMG 却没有加载。

目前，在恩智浦专家的支持下，内部调查仍在继续。

主题已关闭。

谢谢！