ELF note 表¶

inspect_elf_notes / inspect-elf-notes 回答以下问题：所选本地 ELF32/ELF64 镜像是否声明了 PT_NOTE 程序头或 SHT_NOTE 节，这些表存储了哪些 note 所有者和类型，以及这些 note 携带了哪些 GNU build-id 或 ABI-tag 字段。它读取文件但不执行该文件，并且不需要反汇编器、调试包或软件包目录。

rea inspect-elf-notes /absolute/path/to/program --json

CLI 会根据调用者的工作目录解析相对路径。MCP 要求绝对文件系统路径，并保留该精确选择：

{
  "name": "inspect_elf_notes",
  "arguments": { "path": "/artifacts/program" }
}

观察¶

内联的 Evidence 结果包含工件路径、SHA-256 和字节长度。tables 列出每个已声明的 note 程序头或节，并在存在字符串表时包含节名称。Zlib 压缩的节名称表会在所选文件大小预算内解压。不支持的压缩类型会使节名称未知并增加一条限制；note 字节仍会被独立检查。每个 entries[] 条目报告所有者、类型、描述符 SHA-256，以及 64 字节或更少描述符的十六进制预览。

当节名称的偏移量超出所声明字符串表范围，或其字节缺少 NUL 终止符时，节名称也会保持为 null。一条限制会解释该缺失名称。当所有已声明的 note 表和条目都被检查时，note 覆盖仍然完整；节名称不可用并不会抹除这些 note 事实。

对于 GNU note，当描述符与该类型匹配时，会填充 gnu.build_id_hex、gnu.abi_tag 或 gnu.gold_version。其他所有者使 gnu 保持为 null。

PT_NOTE 和 SHT_NOTE 会被独立检查。当两个表都声明同一文件范围时，该范围可能出现两次。

表列表缺失即观察不到这些声明。这并不能证明该镜像从未在另一个容器或 overlay 中携带过 note。

限制与失败¶

所选文件默认限制为 64 MiB（最大 512 MiB）。默认情况下，每个表中最多检查 32 个 note 条目。保留的 note 名称、节名称和 GNU 描述符文本共享一个扫描预算，该预算基于源字节加上任何已解码的节名称表，并以 max_file_bytes 为上限。原始源和已解码的表也必须一起适合该上限。如果接纳失败，错误会报告所需的 max_file_bytes；提高该值可在操作的 512 MiB 上限之内接纳已解码的表。一旦被接纳，提高该设置不会增加针对同一源和已解码名称的扫描预算。重复的表范围会再次计入。每个描述符范围会被哈希一次，每个 GNU 版本的尾部 NUL 序列会被扫描一次；这两次遍历都不能超过该字节上限。格式错误的 ELF 头、截断的头表、声明超出文件末尾的 note 表以及截断的 note 条目都会失败，而不会部分成功。不支持 ELF 扩展编号（PN_XNUM，包括 e_shnum 为 0 时存储的节计数），并返回 unsupported-target 结果，而不是无效输入恢复。

SHF_COMPRESSED note 节会在解释或解压其载荷之前返回 unsupported_target。其压缩头是存储元数据，而非 note 头。当前结果需要每个 note 和描述符的物理文件偏移量，而已解码的压缩 note 无法提供这些偏移量。此拒绝不会将压缩 note 存储标记为格式错误，也不会分配其声明的解码后大小。压缩的节名称表在上述限制内仍然受支持。当需要这些 note 时，请检查单独解压的副本，并保留原始工件以供溯源。

此工作流不会执行镜像，也不会对照软件包目录验证 GNU build-id 的唯一性。