环境一开始是基于2512_LTS openUBMC出的自研版本，刷了自签名的csr包。
后面刷成华为的V3 iBMC版本，BMC起来后发现扩展板没有加载，查看log发现验签失败：
请问这个签名验证是验证EEPROM签名么？只有扩展板会验证么？这个验签流程在检查sr的DataVersion之前么？
答案内容由AI生成，仅供参考：
总结：
- 该日志中的签名验证确实是针对 EEPROM 中 sr.bin 的数字签名（对应
LoadStatus = 2）。 - 此验签并非扩展板独有，但当前错误导致扩展板无法加载。
- 验签流程是加载 sr 数据的前置条件，因此必然在检查 sr 的 DataVersion 之前执行。
点击此处查看详细分析解答
根据提供的 Context（知识图谱与文档块），针对您的问题回答如下：
1. 该签名验证是验证 EEPROM 签名吗？
是的。
文档块明确说明：“Eeprom 数据在加载时会进行类似固件升级的数字签名校验”，并且指出 LoadStatus = 2 明确表示“数字签名校验失败”。
日志中显示的 ECDSA_do_verify failed 和 Signature verification failed 正对应此种情况。此外，知识图谱实体 Eeprom Data 与 Digital Signature Verification 的关系描述为：“Eeprom Data must pass digital signature verification upon loading to ensure trusted firmware”，进一步确认该验证是针对 EEPROM 中存储的数据（如 sr.bin）的数字签名。
2. 只有扩展板会验证吗？
不限于扩展板，但本场景中发生在扩展板加载过程。
日志显示错误发生在组件位置 0101（扩展板），且系统提示“扩展板没有加载”。知识图谱描述 Eeprom 存在于多种硬件（downlink cards, riser cards, power modules 等），所有包含 EEPROM 的组件都可能进行签名验证。例如 CSR 数据、FRU 信息等在加载时均需通过签名校验。因此，虽然当前日志仅涉及扩展板，但系统中其他带 EEPROM 的组件（如主板、电源模块等）同样会执行签名验证流程。
3. 验签流程在检查 sr 的 DataVersion 之前吗？
是的，验签在获取 sr 之前发生，自然在检查 DataVersion 之前。
日志时间线显示：
- 首先出现
ECDSA_do_verify failed（签名验证失败）； - 随后立即输出
fail to get component sr, error: Signature verification failed，表明签名验证失败直接阻止了 sr 数据的获取。
文档块指出：“若出现 LoadStatus = 2，应检查 Eeprom 数据是否由正规工具签名后烧录”，以及结论“数字签名验证是安全验证失败，优先级高于普通格式或 CRC 错误”。这意味着系统在尝试读取和解析 sr.bin 内容之前，必须先通过签名验证。因此，验签发生在任何版本检查（如 DataVersion）之前，验签失败则无法进一步处理 sr 数据。
总结：
- 该日志中的签名验证确实是针对 EEPROM 中 sr.bin 的数字签名（对应
LoadStatus = 2）。 - 此验签并非扩展板独有，但当前错误导致扩展板无法加载。
- 验签流程是加载 sr 数据的前置条件，因此必然在检查 sr 的 DataVersion 之前执行。
这是因为板子上刷了自签名的CSR，使用BMC Studio生成的CSR里面带有伙伴公钥，配套的BMC必须要带上伙伴私钥才能签名校验成功
所有板子都会校验签名，iBMC版本中无伙伴私钥，所以会校验失败，导致CSR加载异常
伙伴的openUBMC中也没有华为的EEPROM私钥，为什么可以正常加载华为的CSR？
我认为是openUBMC版本自带了华为密钥
1 个赞
环境上导入过伙伴根吗？
更正下 应该是内置ECC公钥了。伙伴只能从openUBMC 的/rootfs/角度去内置。
1 个赞
没有导入过伙伴根
从实际情况看感觉openubmc好像没有开启EEPROM签名校验一样，因为我将一个自签名的bin文件从后面删除了一大部分（这样肯定导致验签不通过），然后将这个故意损坏的文件烧录进EEPROM，openUBMC依然可以正常加载该csr
学习了这篇文章，不知道这样理解对不对，还请指教
核心是BMC设备是否存在device_desc_pubkey.bin这个ECC公钥(华为可能不是这个名字)，hwdiscovery组件会根据这个ECC公钥存在与否进行校验，如果不存在则不对CSR进行ECC校验，如果存在则进行校验。
根据bingo的demo，和近期SIG组评审，伙伴的ECC公钥需要单独配置生成，在bingo和BMC Studio出CSR的时候，并不会主动进行ECC签名，只会进行外层hpm中的CMS签名，也就是rootca，
所以就会产生，华为BMC无法自发现伙伴板卡，伙伴能自发现华为板卡。
我们自己的ECC signserver remote 签名会进行校验，bingo 本地的ECC签名是没有校验。然后软件内置是在rootfs下面内置。当前校验存在一些BUG，所以有些人会发现一些问题，这是正常的。不过你说的伙伴能加载华为的CSR，实际上是应该还是内置了ECC 公钥。这应该和伙伴根没关系我觉得。这部分不属于security，这只是完整性校验。
1 个赞
更正下：我看了下，如果是discovery 组件，这个应该是属于闭源组件，从我判断，目前应该是闭源组件内置了ECC 公钥，而不是芯片内置了（之前也许可能判断会过于武断），因为这部分和security 无关，所以应该不存在security sig 不了解的地方。因为discovery conan里面有eeprom_config.lua 字节码，因为ECC公钥bin不大，直接写死都可以。
CSR HPM 升级验签和 CSR/E2P 加载验签是两条链路。HPM 升级验签负责确认升级包外层是否合法；
通过后才会解包并进入 hardware 侧 CSR 写入逻辑。
CSR/E2P 加载验签由 discovery 在运行态解析 EEPROM/CSR 内容时执行，确认设备描述数据本身的完整性。
无 ECC 签名 或 ECC 公钥错误通常不会卡在 hardware，而是会在 discovery 加载校验阶段失败；
只有 digital_sign_offset 等结构字段异常时，才会提前导致 在开源组件这里升级 失败，bingo 无签名是打一串0。
目前结论是在升级阶段是无校验。核心校验就如你截图的应该是属于discovery 组件。
所以目前如果没有公钥，那必然会验签失败，甚至你升级没有任何阻拦，包括公钥和rootfs存放的公钥不匹配的同样也会升级成功，即：只要升错，能救回去的只有用原生 的闭源组件里面的公钥的csr包升级去救回去。
1 个赞