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.

[参考译文] SafeTI:文档质量极差

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/580236/safeti-extremely-poor-documentation

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

您好!

首先、我必须说、这个 SafeTI 文档非常糟糕(并且示例项目几乎和文档一样糟糕、因为这些项目在启动时没有使用 SafeTI 功能、也没有执行所有测试、而 IAR 和其他测试有一些细微的差异... Windows 风格的"帮助"就像一个笑话、它看起来是从源代码生成的、而不提供任何有用的信息。

您还提到了 SafeTI 示例只是一个示例的每个地方-我想说它只是一个_坏_示例:)并且实施者有责任选择正确的测试并正确执行...

-如果该示例得到正确的制作、则此工作将会更加简单->在引导中执行所有可能的测试等。这样人们就可以基本地敲入代码以离开必要的测试、现在您实际上必须从头开始执行所有操作。 当每个人都必须单独确定事情时、适当的示例还可以为实施者节省数千小时的工作量。

我在这里只列出我遇到的几个问题
===========================
问题1)哪个测试类型映射到安全手册中的哪个唯一标识符?

例如、让我们看看闪存/ECC、SafeTI 提供了这种测试类型

- FEE ECC 数据校正模式

- FEE ECC 测试模式1位

- FEE ECC 测试模式2BIT

- FEE ECC SYN_REPORT_MODE

- FEE ECC 故障_MODE1

- FEE ECC 故障模式2

- FLASH_ECC_TEST_MODE_1位

- FLASH_ECC_TEST_MODE_2BIT
- FLASH_ECC_ADDR_TAG_REG_MODE //例如、这在引导序列中的#if 0内

- FEE ECC ADDR_TAG_REG_MODE //例如,没有人在引导序列中调用此操作

和列出了闪存函数的以下唯一标识符

FEE1 FEE 数据 ECC SL_SelfTest_Flash  //注意、闪存功能测试 FEE

FLA1闪存数据 ECC SL_SelfTest_Flash

FLA10闪存包装程序诊断模式5测试 sl_SelfTest_Flash

FLA11闪存包装程序诊断模式7 SL_SelfTest_Flash

奇偶校验逻辑 SL_SelfTest_Flash 的 FLA12软件测试

所以我们有5个唯一的标识符和3个测试类型 这意味着某些测试类型会使多个唯一标识符成为唯一标识符、但哪些是唯一标识符?

这些用于 FEE 功能:

FEE8闪存包装程序诊断模式1测试 SL_SelfTest_FEE

FEE9闪存包装程序诊断模式2测试 sl_SelfTest_FEE

FEE10闪存包装程序诊断模式3测试 SL_SelfTest_FEE

FEE11闪存包装程序诊断模式4测试 SL_SelfTest_FEE
- 4个唯一标识符和7个测试类型(显然需要多个测试类型来填充一个唯一标识符、但填充哪个是唯一标识符)

================================================================
问题2)是否允许修改 SafeTI 的源代码(通常情况下不会这样说)、通常情况下、安全软件会提供 CRC 或其他一些方法来验证源代码是否完整。

——这在任何地方都没有说过……

由于 sl_ESM、SafeTI 代码无法与(OS 和)传统中断一起使用。 在中断处理函数中包含__IRQ 和__Fiq 关键字(当然包括任何文档),这将导致堆栈/PC 损坏,同时在调用这些函数后尝试返回到高级 IRQ 处理程序...
================================================================

问题3)对于故障插入测试类型、返回值没有意义、即返回给它的值。 我们以 PSCON_SELF 测试错误强制_FAULT_INPUT. 在这种情况下、没有人提到不应检查返回值。

   tStatus.stResult = ST_FAIL;

   BRT = sl_SelfTest_PSCON (PSCON_selfTest_error_Forcing_FAULT_Inject,true,&tStatus);

   DBG_PRINT ("Ret:%u、Stat:%s\r\n "、 Bret、tStatus.stResult = ST_PASS? “通过”:“失败”);
-->

RET:1、Stat:失败


   tStatus.stResult = ST_PASS;

   BRT = sl_SelfTest_PSCON (PSCON_selfTest_error_Forcing_FAULT_Inject,true,&tStatus);

   DBG_PRINT ("Ret:%u、Stat:%s\r\n "、 Bret、tStatus.stResult = ST_PASS? “通过”:“失败”);
-->

RET:1、STAT:通过

===========================
问题4)对于窗口帮助和源代码,请参阅过时的函数 SL_SelfTest_PBIST_ExecStatus()

===========================
问题5) SafeTI 安全手册第6.1章规定、应遵循_may _中所述的 init 命令... 很好、示例在这里有一些东西、但没有任何东西映射到任何东西... 没有人提到、例如、在使用 SafeTI 函数执行此操作时、此阶段包含什么内容

29.运行 CPU SECDED 逻辑自检以访问主数据 RAM (B0TCM 和 B1TCM)(第2.24节)。

是所有这些还是其中的一部分、还是 IT 实施者的决定????

- SRAM_PAR_ADDR_CTRL_self_test

- SRAM_ECC_ERROR_ENCERAING_1位

- SRAM_ECC_ERROR_性能 评测

- SRAM_ECC_ERROR_ENCED_2BIT

- SRAM_RADECODE_DIAGNOSTICS //这在相位~42 ESMInit()之后的 SafeTI 示例中运行

- SRAM_LIVECLOCK_DIAGNOSTICS //在示例引导序列中根本不运行

===========================
问题6)如果启用了 FIQ 中断(不想显示哪些中断:)、那么至少在调试器复位后、无法运行 SafeTI 示例中的某些启动时间测试- CPU 崩溃到未定义的指令也是很好的... 调试器复位后、CPU 寄存器中的 FIQ 为1、但

===========================

问题7) sl_config.h 中的堆栈定义是愚蠢的、+甚至不在 SL_ASM_API_IAR.asm 中使用这些定义!!!! 它再次定义了这些内容,甚至不包括 sl_config.h :)。 因此、如果不想使用默认设置、您必须将自己的 ASM-function 写入初始化堆栈、因为只有其他选项可以修改 SafeTI 源代码。

此外、IAR 设置堆栈的链接器脚本很糟糕、通过"微调"、您可以定义堆栈、以便仅在一个位置(在链接器文件中)给出长度、并且链接器还会监控为堆栈保留的空间是否未超出- 当前的 SafeTI 解决方案远不及这个问题--必须编写自己的堆栈初始化函数,该函数使用链接器提供的符号,如 SVC_STACK_$LIMIT。
 ===========================

问题8) Init 文档没有提及任何内容。 _errata_CORTEXR4_66_()、ja _errata_CORTEXR4_57_()和 errata_PBIST_4 ()。 执行这个操作的实际正确位置是什么、HalcogGen 代码有很多错误、以至于没有石膏、HalCoGens 对于这些错误的放置是正确的...

关于 errata_PBIST_4 (),您明确地推荐了论坛中不应使用 select.c 例程而应使用 SafeTI-routines 的每一个地方--这不是例程,因此必须根据建议使用 select.c。。。

===========================

问题9)由于某些自检.c 功能仍在使用,因此需要在自检故障通知()中实现某些功能,因为此函数可能从某个位置调用... SafeTI 文档不会指导用户在此处放置一些合理的代码

===========================

问题10) SafeTI 文档不提供任何检查列表、如9中提到的问题已得到处理...

===========================

问题11) FIQ 和操作系统(操作系统)以及 FIQ 中断不能被屏蔽(除非手动将 CPU 更改为 FIQ 模式)这一事实、文档中对此没有提及、如果尝试使用 FIQ 处理程序中的操作系统服务、则必须进行一些特殊处理... 尚未真正对此进行过控制,但至少 uC/OS 会尝试禁用 CPSR 中的 IRQ&FIQ 位(启用 FIQ 后无法禁用),之后,操作系统会相信在执行自身的神奇操作时不会发生上下文切换。 通过简单看、看起来不能从 FIQ 调用 OS 例程、因此、如果 ESM 变为高电平、则需要使用其他一些方法来处理它... 可能其他一些操作系统或 uC/OS 端口已经解决了这个问题。

===========================

这些已发布的产品中有"百万"件、但我在此停留、这只是表明 SafeTI 成熟度远远没有"仅将"安全集成到项目中。 我花了几天时间(实际阅读数周)来制作链接器脚本、拥有 ASM 堆栈初始化程序、正确的引导序列(甚至还没有完成)、方法是使用 SafeTI 功能"仅"、它能够通过 RAM pbist&init 存储测试结果... 我100%确定每个人都必须遇到相同的情况、首先弄清为什么在启动中的特定测试完成后会给出用于调试器复位的未定义指令、为什么即使在 sl_config.h 和链接器中正确设置了所有内容、堆栈也会溢出等等 (这些设置不会帮助 ASM 覆盖它们:)(不有趣)...

我还100%确信、如果编码和 Hercules 安全功能方面的专家能在几天内让当前的 SafeTI 示例变得近乎完美-我想知道 TI 为什么没有这么做、那么当前的情况与营销材料相去甚远... 当前示例编译就是这样。 修复此示例后、需要更多的时间来修复文档、当前唯一的标识符列表以及到 SafeTI 函数的映射(当然没有测试类型...) 它仅提供有价值的信息...

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

    很抱歉、您在将 SafeTI 元件集成到应用中遇到了很大困难。 当然、在使用产品时有一些学习曲线。 我将您的疑虑转交给我们的管理团队、因为我认为某些观察结果肯定会指出我们有很大改进空间的领域。 当我听到他们关于与您所概述的问题有关的任何具体行动方案时、我会告诉您。 我不希望逐个列出您的清单项目、而是希望我们专注于各个问题、并尝试一次解决这些问题。 首先、与我们的软件团队建立电话联系以解决您对集成 SafeTI 诊断库的一些担忧可能会有所帮助、请告诉我、我可以对此进行设置。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    如果您觉得电话会有所帮助、我仍然更喜欢通过电话发送电子邮件、因为我不是母语的英语扬声器、当事情发展到真正的技术时... --嗯,你知道...

    我尝试在列表中列出最重要的列表(并将一些次要列表输入到组合中)。 我个人认为我已经解决了初始化例程中的所有可能问题,目前具有“完美和稳健”(代码永远是完美和稳健的:)初始化例程,它遵循您建议的 CPU 初始化实际逐阶段执行,只有 PBIST4勘误表来自 selftest.c, 由自己进行的几项"测试"(从原理上模拟自检.c 功能)、然后使用 SafeTI 进行其余测试。 在 INIT 例程中、我决定在第38阶段之前执行 PSCON 测试...)。

    但是,我当然仍然不知道这是不是正确的,至少从逻辑上讲,SafeTI 接口提供的“所有测试”在启动时执行:),代码在调试器的配合下和不在调试器的配合下工作,如果调试器未连接,则进行 STC 和 CCM 测试。


    我同意、当然、您所做的任何事情都有学习曲线、但目前 SafeTI 的学习曲线过于陡峭、我不得不学习 ASM、链接器脚本、 VIM 和 ESM 中的所有详细信息、当然我必须阅读 SafeTI 源10次、并且 TRM 和数据表持续+还要研究 CPU 的 ARM 文档。 我并不是说我被迫挖掘所有细节是件坏事(至少我觉得我现在对 SafeTI 和相关功能的总体了解相当好)。 但不应强迫人们这样做,因为大多数"致命问题"都来自"非常简单的事情",因此在示例代码(和文档中)中处理这些问题确实很容易。

    当然、始终会出现"是否应在该测试之前执行此操作"或"为什么此测试看起来不起作用"等问题、但我宁愿回答这些问题、而不是"为什么我的代码跳转到未定义的指令"。

    ===================
    我刚刚注意到问题6遗漏了一些文本(很难在没有预览选项的较小窗口中写入文本)。

    它应该是这样的:
    问题6)如果启用了 FIQ 中断(不想显示哪些中断:)、那么至少在调试器复位后、无法运行 SafeTI 示例中的某些启动时间测试- CPU 崩溃到未定义的指令也是很好的... 在调试器复位 CPU 程序状态寄存器中的 FIQ (F 位)后,当执行 sl_Init_R4Registers ()时,它会自动通过这    条 MRS R1 CPSR -command 重新启用,F 位变为0,表示启用了 FIQ (如果我从 ARM 文档中正确理解, 这是读取命令、它如何修改 CPSR???)
    --------

    下面对问题6进行了一些分析(我认为这是最关键的问题之一(与堆栈初始化一起)、因为代码的行为是完全不可预料的):
    问题测试当然是 ESM 组2测试、因为这些测试无法屏蔽、而 SafeTI 对组1测试所做的就是这样。 测试完成后、SafeTI 确实会确认 gorup2的 ESM 源、但在禁用 FIQ (在该阶段的常规引导中仍会禁用)的情况下、不会从 VIM 中获取这些 ESM 源)、方法是使用语法:
    vimREG->INTREQ0 = 1U;

    因此、您必须在测试完成后在应用中确认(我认为 SafeTI 文档应该提及这一点)。

    如果没有该手动信息、在常规"首次启动"中会有 VIM 请求等待在 CPSR 中启用 FIQ、并且 FIQVECREQ 不包含正确的矢量(导致 VIM RAM 初始化尚未初始化、发送给 FIQVECREQ 的矢量为0x3c3c3c3c3c3c 或类似的内容) 如果在 vimInit()之前进行了与组2相关的测试(如果遵循 init-sequence 则完成这些测试)。 出于某种原因,如果在调用 vimInit()之前调用 vimInit(),则 vimrambase 写入会将 IRQVECREQ 和 FIQVECREQ 中的内容替换为 vimram 基本内容(默认情况下为幻象中断),然后 FIQ 启用 VIM 会将以前生成的0x3c3c3c3c3c 矢量替换为 viqVECREQ 中的 vimoninterrupt -- 这是一些隐藏的功能、但 TRM 中没有提到过、vimrambase 写入会带来一些神奇)... 现在、如果在没有手动 VIM CH1确认代码的情况下启用 FIQ、代码将跳转到模块中断、并且每次在常规上电启动时、您都会得到模块调用。

    如果您在调试器复位后执行此类测试(如果在复位前启用了 FIQ、则启用该测试) 当它将立即跳转到 FIQ 时、例如 INIT 例程会指示 VIM 在第28阶段的 PBIST、然后在第29阶段测试 SRAM、该 SRAM 会断言 FIQ、该 FIQ 随后会跳转到0x3c3c3c3c、因为 PBIST 已损坏矢量表且 FIQ 已启用、因此它跳转到 地址损坏、同样适用于第30阶段闪存测试。

    例如、我通过在某些测试(即组2相关测试)之后始终手动确认 VIM CH1来解决此问题(在我花了大量时间来找出问题的根本原因之后)。 这可以防止虚拟调用、并确保在启用 FIQ 时根本不驱动测试->防止地中止、这样您就可以使用调试器执行所需的操作(无论何时需要、都可以重置 CPU、 如果您在组3测试尚未从 ESM 中进行攻击时使用调试器重置 CPU 初始化阶段7陷阱-这是我遇到的唯一问题)、并且您将永远不会在引导序列中看到省级中止或幻象中断调用...
    -如果 SafeTI 文档显示在这些特定测试的 SafeTI 内部未处理待处理的 VIM 请求、并且您必须在某些情况下(未启用 FIQ)手动执行此操作(示例代码可能会执行此操作)、我将节省大量时间、 我非常确信、如果代码甚至稍微遵循示例代码或建议的初始化例程、每个人都会看到虚拟中断... 如果将调试器重置抛出到混合,则它将被利用:)。

    或者,人们可能会争辩说,在调试器复位后再次运行整个 init sequnce 是可行的,但这是另一个问题(我仍然非常确信,在执行初始化例程时,您将非常需要重置调试器-- 因此,文件中的一些"警告"将是非常值得欢迎的)。 堆栈未存储、因此无法遵循可能的 CPU 复位模式、可能会设置一些标志来跳过初始化模式中的某些内容、或者像我所做的那样跳过基于 CPU FIQ 状态的某些测试。 但无论如何、我认为 应该在 SafeTI 手册中对其进行说明(如果将其实施到示例代码中、则更好)...

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

    非常感谢您对我们的工具和文档的见解和评论。 我完全承认、在文档、软件和工具集合中仍有一些缺口需要填补、这可以使我们的所有客户更加轻松。 当然、其中一些漏洞是故意存在的、因为我们尝试在示例和库的使用方式上保持灵活性、而其他漏洞是由于时间、计划、优先级和一般资源限制等其他限制。 当然、这些都还在开发中、实际上、随着我们进一步了解如何使用它们、可以更好地优化示例和参考代码、这一过程将持续一段时间。

    现在、我将向您发送我的直接电子邮件信息、以便我们可以在您选择时进行更详细的讨论。 如果我这样做,如果你能作出实物反应,我将对你的每一个观点提供一些额外的细节,也许可以说明我们目前的情况和我们希望在不远的将来的情况。