[参考译文] AM69：Keywriter mSv 编程和其他相关问题

尊敬的 Diwakar：

感谢您的快速重播。

1.因此,基于 n 这个逻辑被恢复。 通常0可以在 OTP 上写入1 -但在这种情况下、effuse 与 OTP 存储有相反的逻辑？ 有没有其他变量可以我测试/播放其他像键?

Unknown 说：

现在、您不能将 F(1111)更改为 E (1110)设置位、从1更改为0。 您可以执行另一种方法、如果该位为0、则可以将效率中的位设置为1。

在提供链接内部、我无法使用  诸如 DEBUG_RESPONSE：0x2000000之类的错误代码、最大为31。 但根据您的答案、可能意味着一些一般的 OTP 写入错误。

2.因此,即使这个标志也会被设置为 rp (例如密钥),  RBL 仍可以对安全映像进行身份验证——对吗?

Unknown 说：

这是一种硬件功能、即使该内核支持 efusse 控制器、也不允许从 effuses 读取。 为了支持 effuss(HW 特性)的安全启动扫描、将在启动时执行、值将映射到 sec_MMR。 这些 MMR 是防火墙的、只有 TIFS 和安全 ROM 可以访问它们。

3、明确,感谢您的确认。

4.哪里做的符号的自定义键的 final_certificate.bin ? 我猜在以下脚本执行期间生成自定义密钥之后、例如：

./gen_keywr_cert.sh -t ti_fek_public.pem -s keys/smpk.pem --smek keys/smek.key -s-rp --smek-rp -b keys/bmpk.pem --bmek keys/-b-rp --mek-opt 0x1 --mpk-rp -keynt --keycnt 2 --bmek-rev -keynt -keynt 1 - keynt -keynt 1 - bmek.key

在此级别上 尚未使用 k3_dev_mpk.pem -对吗？

BTW MPK/MEK OPT 选项标记是什么意思？ 似乎保留、未记录。

接下来在 将 final_certificate.bin 包含到 Keywriter 二进制文件并 完成签名操作之前生成的代码 经由  k3_dev_mpk.pem 签字人：

设置 keywriter_img_combined board=j784s4_evm

在这个级别上、 k3_dev_mpk.pem 用于对 Keywriter - ok 签名。  我知道签名可以优化 HS-Keywriter 在 FS 上的引导 (类似 tiboot3.bin 在 hs-fs 上运行的符号)、但这也可以通过 TI 虚拟密钥而不是通过客户密钥来完成(重要的是、用于从 HF-HF FS 转换到 HS_SE 的自定义 finall_certification)。 为什么在进行 Keywriter 操作期间需要此级别上的自定义密钥-这仍然不清楚。 您能 解释一下吗？

最后 、SPL/Uboot 映像应由自定义密钥签名。

此致、

Dariusz Gasiorowski

尊敬的  Dariusz ：

bin li26 说：

1. 因此、根据这一点、逻辑会被恢复。 通常0可以在 OTP 上写入1 -但在这种情况下、effuse 与 OTP 存储有相反的逻辑？ 是否有任何其他变量可以测试/播放其他类似键？

OTP 只是效率、本质上、一旦设置了该位、就无法将其复位。 这里的具体目标是什么?,如果你只是想测试 Keywriter 是否工作正常,我们建议客户用 override 标志写第一个 MSV。

bin li26 说：

在提供链接中   、我无法找到错误代码、如 debug_response：0x2000000、最大值为31。 但根据您的答案、可能意味着一些一般的 OTP 写入错误。

提供的链接包含所有错误代码、我们需要检查该位在调试响应中的位置。 如果 设置了 debug_respone 0x2000000第25位、如果我们将其映射到表、则会因为未能将 MSV 编程到效率中而收到错误。

bin li26 说：

4. 哪里可以通过 final_certificate.bin 的自定义密钥进行签名？ 我猜在以下脚本执行过程中自定义密钥生成后、例如：

k3_dev_mpk.pem 只不过是一个 SMPK (Priv)密钥。 我建议您浏览以下链接、了解它如何在 Keywriter 中被使用以及在稍后阶段用于对映像签名。

• https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/key_writer.html#procedure
• https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/authentication.html#authentication-sequence

在浏览文档后、如果您对此仍有疑问、请告知我

BTW MPK/MEK OPT 选项标记是什么意思？ 似乎保留、未记录。

 保留字段、并在 TISCI 文档中进行了说明。

 software-dl.ti.com/.../key_writer.html

此致
Diwakar

尊敬的 Diwakar：

bin li26 说：

因此、即使此标志也会设置为 rp (例如密钥)、  RBL 仍可以对安全映像进行身份验证-对吗？

#1。 是的、我同意-这是 OTP 的性质。  

Unknown 说：

OTP 仅为效函数、在设置该位后、您无法重置该位。 此处的确切目标是什么？

但我的手册更笼统地讨论了标准 OTP。

在传统的 OTP (一次性可编程)存储器中、一旦一个位被编程为0x00 (或0)、它就无法更改回0xFF (或1)。 这是 OTP 存储器的基本特性–它是"一次性"可编程的。 您只能从高电平(通常为0xFF、表示未编程或已擦除的状态)写入低电平状态(0x00、表示编程的状态)。 尝试向已写入0的位写入1将被忽略。

"一个位被编程为0x00 (或0)后、它无法改回0xFF (或1)"语句适用于典型的标准 OTP 存储器、其中一个位只能写入一次。 这是一个不可逆转的过程。 "0"表示"已编程"、"1"表示"未编程"。  

但是、如果文档中的此 SoC 中使用了 OTP Fuse、也可以根据您的答案类似、如下所示：

"一旦一个位被写为‘1'、该位就无法更改。
只要写入的模式不会导致尝试将现有的‘1"更改为‘0"、就可以多次写入"扩展 OTP 保险丝"行。 这种情况将导致写入错误。"

这意味着逻辑与用户的观点相反-可能这会在低电平 OTP 访问时以电气方式反转。 "我知道你喜欢我。" 我希望这一澄清对你们也是清楚的。

感谢对错误代码 的澄清,我没有读出它是关于位位置。

#2. 请确认我关于使用(通常为-rp)的要点、例如-s-rp 标志、例如 smpk：

bin li26 说：

因此、即使此标志也会设置为 rp (例如密钥)、  RBL 仍可以对安全映像进行身份验证-对吗？

#4. 是的、我看到 OPT FILE 被描述为保留、但在 TI 示例自述文件中使用了此示例、例如："--MEK-OPT 0x1 --MPK-OPT 0x21"-这是我的问题、这意味着什么？ 因此、如果仍然保留可以。

接下来, 请原谅我,但我知道这些链接,没有回答我的问题 k3_dev_mpk.de 我也知道它:

Unknown 说：

k3_dev_mpk.pem 只不过是一个 SMPK (Priv)键

这个密钥的主要问题是在"make"编译中使用的、特别是为了支持我的 HSM 编译过程、该构建过程应该能够容忍最小的编译依赖性。 我仍然不知道为什么要 在"make"构建过程中使用自定义版本。 可以清楚地看到、使用一些虚拟 smpk 对 Keywriter 进行签名、但这不解释 在 HS-SoC 上运行 Keywriter FS 的自定义版本的用法。  另外、很明显、应 通过 gen_keywr_cert.sh 使用定制 smpk、以生成 转换为 HS-SE 所需的 final_certificate.bin。

应届毕业生、

Dariusz Gasiorowski

我检查其他电路板是否进行 mSv 编程。

./gen_keywr_cert.sh -t ti_fek_public.pem --mSv 0x00001

* MSV:
[u32] BCh + mSv：0x53900001
编程 MSV 时出错
DEBUG_RESPONSE：0x2000000
[u32] BCh + mSv：0x53900001

调试响应：0x0
钥匙编程顺序已完成

下一步

 ./gen_keywr_cert.sh -t ti_fek_public.pem --mSv 0x00003 --mSv-OVRD

* MSV:
[u32] BCh + mSv：0x53900001
编程 MSV 时出错
DEBUG_RESPONSE：0x2000000
[u32] BCh + mSv：0x53900001

相同的

 ./gen_keywr_cert.sh -t ti_fek_public.pem --mSv 0x00002 --mSv-OVRD

但在本例中、我预计会失败、因为0x02无法写入0x01

此外、接下来我重新检查是否为0x01、在这种情况下输出成功。

为什么0x03未覆盖为0x01？  可能由于 BCH 零件内部存储/计算而无法覆盖 mSv 的情况？

此致、

Dariusz Gasiorowski

您好、 Dariusz

您的日志清晰、请将共享、因为它是来自设备的日志。

* MSV:
[u32] BCh + mSv：0x53900001
编程 MSV 时出错
DEBUG_RESPONSE：0x2000000
[u32] BCh + mSv：0x53900001

调试响应：0x0
钥匙编程顺序已完成

为什么在同一个测试案例中失败和成功?

bin li26 说：

 如果 mSv 由于 BCH 部件内部存储/计算而无法覆盖？

效率中的 MSV 字段为20位值、带有12位 BCH 码、BCH 会根据输入数据而变化、因此不同的值会有所不同。

此致
Diwakar

是的、这是可能的。已对上一个响应做出响应。

Unknown 说：

为了支持 effuses (HW 功能)的安全启动扫描、将在启动时执行、并将值映射到 sec_MMR。 这些 MMR 是防火墙的、只有 TIFS 和安全 ROM 可以访问这些文件。

bin li26 说：

此密钥的主要问题是在"make"构建中使用的、尤其是为了支持我的 HSM 构建过程、该过程应该可以容忍最小构建依赖项。 我仍然不知道为什么要 在"make"构建过程中使用自定义版本。 可以清楚地看到、使用一些虚拟 smpk 对 Keywriter 进行签名、但这不解释 在 HS-SoC 上运行 Keywriter FS 的自定义版本的用法。  还可以清楚地看到、应 通过 gen_keywr_cert.sh 使用自定义 smpk 来生成 转换为 HS-SE 所需的 final_certificate.bin。

如果我正确理解你的问题,你想知道为什么这是需要构建 Keywriter 应用映像,是这个问题?

此致
Diwakar

如果我正确理解你的问题,你想知道为什么这是需要构建 Keywriter 应用映像,是这个问题?

此致

是的、正确。 如果内部包含  final_certificate.bin 的自定义版本、为什么需要使用 SMP 的自定义版本来编译 Keywriter ？  (与命令、脚本、执行上一个问题中所示)

关于  OVRD mSv、是的、这是错误粘贴调试(绿色)输出线路、  在这种故障情况下、来自 MCU UART R5内核的正确日志为：

调试响应：0x2000000
钥匙编程顺序已完成

 WKUP UART M4内核时：

* MSV:
[u32] BCh + mSv：0x53900001
编程 MSV 时出错
DEBUG_RESPONSE：0x2000000
[u32] BCh + mSv：0x53900001

但这说明建议 mSv 的新值不能正确存储,因为 ne 计算的 BCH 值-我是对的? 如果"是"不能覆盖它？

Unknown 说：

msv 字段在 effuses 是20位值与12位 BCH 代码、BCH 将根据输入数据更改、因此它将是 dif

感谢您的支持

此致、

Dariusz Gasiorowski

Unknown 说：

这用于对 Keywriter 映像执行完整性检查。您可以保留虚拟密钥或 ROM_degenerateKey.pem 密钥来代替此

很棒的信息！ 谢谢。 我会检查一下。  我假设在此操作之后和转换到 HS-SE 后、不应该影响通过自定义密钥对已签名映像进行的密钥引导身份验证。

用户只提供 mSv , BCH 是计算和存储的,所以看起来像 -- mSv-OVRD 没有意义。 我的意图是运行一些多通道测试:-)  但我真的不想冒险这样的操作的密钥

以下是首次将 mSv 0x01写入默认值0x00时来自 M4的完整日志：

e2e.ti.com/.../msv_5F00_01.txt

以下是覆盖 mSv 0x03至存储的0x01期间从 M4的完整日志。

e2e.ti.com/.../msv_5F00_03.txt

BCH 代码和 MSV：0300b0f4  -这是 mSv 0x03值与 cert 的新 BCH 吗? mSv + BCH 的 顺序相反？

此致、

Dariusz Gasiorowski