ELF二进制文件是否存在等效于PE Original Filename的属性？

结论先说：标准ELF格式规范里，没有强制设计和PE"Original Filename"完全对等的、专门记录构建时原始文件名的专用属性，实际生态里能实现类似追溯效果的机制分几种情况，和PE的实现逻辑差异很大：

• 编译器可选写入的非标准段信息
  部分编译器、构建工具生成ELF文件时，会把构建辅助信息写入.comment注释段或者自定义.note段，但这完全是工具的可选行为，不属于ELF标准强制要求的内容。这类信息默认不会被纳入常规的ELF签名校验范围，还可以通过strip等工具轻易修改、删除，几乎没有防篡改能力。而且绝大多数常规构建场景下，这些段里只会存编译器版本、构建时间戳这类内容，不会主动写入原始文件名。
• 签名/包管理体系的外部关联记录
  目前Linux生态常用的ELF完整性校验方案，不管是内核级的IMA签名、sigstore应用签名，还是发行版自带的deb/rpm包校验，都不会把原始文件名作为字段内置到ELF文件结构里，而是把文件路径、原始文件名这类信息存在独立的签名元数据、软件包文件清单中。举个例子，你从apt源装的ls命令，deb包的元数据里确实记录了这个二进制原本要安装到/bin/ls路径，但你要是把这个ELF单独复制出来重命名成别的名字，文件本身不会带任何可直接读取的原始文件名痕迹。
• 可间接追溯的Build-ID机制
  现在主流编译器默认都会开启--build-id编译选项，给每个生成的ELF写入一个和文件内容哈希绑定的唯一构建标识，存在ELF的标准note段里。这个ID本身不存储任何文件名信息，但你可以通过它匹配到对应发行版源、构建仓库里的公开记录，间接查到这个二进制原本的名称和发布路径——只是这种追溯必须依赖外部的记录数据库，没法靠单个ELF文件直接读属性判断。
• 可自定义实现等效能力
  如果要完全复刻PE签名场景下的效果：即文件被重命名后，能直接从文件本身读出原始文件名，且修改文件名相关记录会直接破坏签名校验，也不是做不到：可以自定义ELF的note段格式，把原始文件名作为自定义元数据封入ELF，同时把这部分元数据纳入签名的哈希计算范围就行，但这属于用户自定义扩展，不是ELF格式的通用标准属性，绝大多数常规发行版的二进制都不会带这类字段。

你可以自己简单验证下：把系统里的/bin/ls复制出来重命名成随便什么名字，用readelf、objdump这类工具遍历所有ELF段，根本找不到专门记录它原本叫「ls」的标准字段，这和PE文件把原始文件名存在内置版本资源里、直接纳入签名校验的逻辑有本质区别。

内容的提问来源于stack exchange，提问作者Cocowalla