SR → xxx.bin → xxx.hpm，中间这层.bin文件参考社区方案，不使用签名。
升级和使用都OK，但是一键收集下来的hwdiscovery路径下的SR，会变成空白。这个麻烦帮忙看一下一键收集的处理逻辑，对.bin是不是没有无签名的处理？
KunLun2280V2_2102315KKWXFR26030171_20260528-0701.tar.zip.001.txt (4.8 MB)
KunLun2280V2_2102315KKWXFR26030171_20260528-0701.tar.zip.002.txt (4.8 MB)
KunLun2280V2_2102315KKWXFR26030171_20260528-0701.tar.zip.003.txt (829.3 KB)
答案内容由AI生成，仅供参考：
解决方案建议在 ~/.bmcgo/config 或 bingo 的配置文件中添加 eeprom_self_sign 配置项，并指定私钥文件。示例配置（来自社区）：
[eeprom_self_sign]
priv_pem=/home/workspace/source/test/ecc_sign/private_key.pem
同时，将对应的公钥文件放置到 BMC 环境的 /opt/bmc/trust/partner/device_desc_pubkey.bin 路径下，以便 hwdiscovery 进行验签。
若使用签名服务器，则配置 eeprom_server_sign 相关参数（参见 bingo 示例）：
[eeprom_server_sign]
url = <签名服务器URL>
hwdiscovery 验签策略（不推荐）如果确需在生产环境中跳过 EEPROM 签名验证（仅限调试），需要修改 hwdiscovery 的配置或代码，但此操作会降低系统安全性，不建议用于正式场景。
关键结论.bin 文件缺少 ECC 签名，导致 hwdiscovery 验签失败，无法生成有效 .sr 文件。hwdiscovery 重新加载，.sr 文件即可正常生成。根据您提供的信息，您遇到的问题是由于 中间层 .bin 文件缺少 ECC 签名 导致的。虽然升级和使用过程中可能表面正常，但 hwdiscovery 在后台处理这些 .bin 文件时，会因为验签失败而无法正确生成对应的 .sr 文件，从而导致一键日志中该目录下的 .sr 文件内容为空（大小为 0）。以下是详细分析及建议。
问题根因分析.bin 文件的签名要求在 OpenUBMC 的 CSR 打包与加载流程中，存在 两层签名机制：
.bin 文件签名（ECC 签名）—— 用于验证被烧录到 EEPROM 中的每个 .bin 文件（即硬件自描述数据）的完整性和来源。根据社区资料（[参考链接]）：
“在CSR出包过程中，hpm包自身使用的是CMS签名，一个CSR包中会有一个或多个可以被烧录到eeprom中的.bin文件，这些.bin文件也是需要进行签名并会进行验签的，所以这个确实是一个独立于hpm包签名的ECC签名私钥。”
这意味着 即使 HPM 包签名通过，内部的 .bin 文件仍必须带有有效的 ECC 签名，否则 hwdiscovery 在启动时对其进行验签会失败。
hwdiscovery 的验签机制hwdiscovery 在初始化时会从 EEPROM 或本地路径（如 /opt/bmc/sr/）读取 .bin 文件，并利用公钥（通常存放在 /opt/bmc/trust/partner/device_desc_pubkey.bin）对其进行 ECC 签名验证。如果验签失败，hwdiscovery 会 拒绝加载该数据，因此无法生成对应的 .sr 文件，或者生成的 .sr 文件内容为空。
日志中可能表现为：
hwdiscovery NOTICE: position: 010102, load sr data successfully...
但实际 .sr 文件大小为 0，说明数据未正确解析。
您提到的 “参考社区方案，不使用签名” 可能是指开发或测试阶段跳过 ECC 签名步骤。然而，hwdiscovery 的默认行为仍然会尝试验签，缺少签名会导致：
hwdiscovery 无法通过验签 → 不生成有效 .sr 数据。.sr 文件，因此看到的是空文件（0字节）。 解决方案建议在 ~/.bmcgo/config 或 bingo 的配置文件中添加 eeprom_self_sign 配置项，并指定私钥文件。示例配置（来自社区）：
[eeprom_self_sign]
priv_pem=/home/workspace/source/test/ecc_sign/private_key.pem
同时，将对应的公钥文件放置到 BMC 环境的 /opt/bmc/trust/partner/device_desc_pubkey.bin 路径下，以便 hwdiscovery 进行验签。
若使用签名服务器，则配置 eeprom_server_sign 相关参数（参见 bingo 示例）：
[eeprom_server_sign]
url = <签名服务器URL>
hwdiscovery 验签策略（不推荐）如果确需在生产环境中跳过 EEPROM 签名验证（仅限调试），需要修改 hwdiscovery 的配置或代码，但此操作会降低系统安全性，不建议用于正式场景。
关键结论.bin 文件缺少 ECC 签名，导致 hwdiscovery 验签失败，无法生成有效 .sr 文件。hwdiscovery 重新加载，.sr 文件即可正常生成。请参考社区文档 ecc_sign 演示 完成签名配置，或结合您的实际环境进行适配。
如有进一步的日志或配置疑问，欢迎继续交流。
打包的hpm升级成功只是外层的签名校验，签名区域全0才会不进行验签，其他是验签失败的，会导致实际上没加载上
HPM 升级阶段
SR/PSR HPM 包升级时，general_hardware 主要处理 HPM 包升级流程，本身不会对 EEPROM .bin 做 ECC 验签。因此即使 .bin 没有做 ECC 签名，HPM 也可能升级成功。
hwdiscovery 加载阶段
升级完成后，真正解析并加载 SR/PSR .bin 的是 discovery/hwdiscovery 相关组件。EEPROM .bin 的 ECC 验签是在这个加载阶段做的，不是在 general_hardware 升级阶段做的。
bingo 在未配置 EEPROM ECC 签名时，会按无签名方式生成 .bin，尾部签名区域会补 0。设备侧加载时如果识别到签名区域全 0，理论上会按无签名兼容路径处理，不走 ECC 验签；如果签名区域不是全 0，则会认为该 .bin 带ECC 签名，并使用设备侧公钥进行验签，如果ECC公钥不匹配也会升级成功，理由是目前general_hardware当前 升级时候不会对ECC进行校验，所以会出现升级成功现象，但是如果ECC 公钥不对，可能导致BMC PSR,CSR都加载不了。
因此，“HPM 升级成功”和“SR/PSR 被 hwdiscovery 正常加载”不是一回事。当前一键收集里 hwdiscovery 路径下 SR 为空，更像是升级后 discovery 加载阶段没有成功解析/加载 .bin，需要重点看 discovery/hwdiscovery 日志，而不是只看 HPM 升级结果。
如果没有加载成功，还是能显示某组件，说明应该用的是/opt/下的sr。
明确ECC签名头是补0的无签名版本。
另外环境上可以观察到内容与预期一致，比如新增的线缆白名单或者调速的修改，明确SR是生效的。但是一键收集依然有问题。
这个你们自己也可以试一下，这肯定不是只有我们这里有问题。
我说的是 升级和使用都OK
目前的场景是：hpm包是我们自己的签名，里面的bin文件的ECC签名是全为0填充的空签名。
这个是经过多次验证的。如果我带了手动搞的ECC签名，会导致对应组件内容空白无法加载，手动打全0为无签名版本，是正常加载的，而且环境上的内容与预期一致，线缆白名单、调速等。
目前的问题是一键收集出来的内容是空白的，这个建议你们内部验证一下看看。
我们很早之前遇到过这种现象过，不过我加了公钥后，现在无ECC签名的升级会直接在firmware_mgmt 失败，不知道是不是因为加了公钥后现在从firmware_mgmt拦截了.现在只会出现ECC公钥不对也能随意升级，原因是general_hardware 没有校验签名，理论上这边要验签这是general_hardware做，还是frmware_mgmt 边界这块我不太清楚。然后我们signserver这块本身做了构建ECC签名有校验拦截，所以不会出现ECC公钥不对的情况。
从运行日志和现有现象看，部分历史 UID 可能存在兼容路径，未签名或验签异常时仍能继续读取；该行为应以具体设备日志中的 component uid … in white list 或 get data without signature verification 为准。
这个是hwdiscovery 里的 LuaJIT bytecode / 闭源产物做 strings、运行态 introspection，看到 uid_white_list、verify signature failed, component uid: %s in white list、get data without signature verification 这些字符串。
实机上用 dofile/upvalue 方式验证 eeprom_configs.lua、cmds.lua/check_integrity 的运行态字段和调用顺序。
日志是空的，大概可能还是因为验签本身失败了，当然这句是我猜测的。
1970-01-01 00:00:38.861651 hwproxy NOTICE: cmds.lua(60): position: 010101, component uid: 00000001020302083825 signature data is empty, skip get signature data.
1970-01-01 00:00:38.862005 hwproxy NOTICE: cmds.lua(301): position: 010101, component uid: 00000001020302083825 get data without signature verification
1970-01-01 00:00:38.871489 hwproxy NOTICE: cmds.lua(60): position: 010103, component uid: 00000001050302023924 signature data is empty, skip get signature data.
1970-01-01 00:00:38.871868 hwproxy NOTICE: cmds.lua(301): position: 010103, component uid: 00000001050302023924 get data without signature verification
你这个也可以问一下，加了公钥没道理空签名的机制就没了。
我这个是明确的，环境上没有加公钥，ECC没有签名，HPM包验签OK，无ECC签名的文件正常加载和使用，资源树对象的数据和修改后的SR一致（不存在从兼容路径或软件打包SR读取的可能）。
目前怀疑的唯一方向就是：一键收集的时候，从Eeprom读取bin文件时有尝试进行解析，而那边没有与固件升级或者SR加载的签名处理保持一致，从而导致一键收集内容为空。
这个后续有说，空签名的也可以正常识别。不在现在的版本
麻烦这个问题优先处理下我们采用社区的无签名方案，目前一键收集里的SR内容都为空，对日常问题定位的效率产生很大影响了。
你好，请问这个问题有进展吗？有尝试复现吗。
无签名包不会将数据从eeprom备份出来，所以本地不会有这个sr文件，一键收集时创建出空文件
无签名包不会将数据从eeprom备份出来，这个是为什么？这个是不是得调整一下。只是bin没有签名，但是依然能从硬件上读取出来bin文件的吧
无签名场景认为不可信
但是这只是读取并打包成bin文件放到一键日志中，并不进行额外的处理动作，应该不会有任意代码执行风险吧？而且这还是你们社区支持的无签名方案，但是到最后还是有一部分功能阉割了，也不合适吧。这部分麻烦帮忙确认一下，我觉得这样很不合理。
应该是目前对无签名包作了兼容处理，正常加载不报错，没有明确支持
