Go debug/elf 的 NOBITS 节为什么有 Size 却无法读取 Data

SHT_NOBITS 节的 Size 描述节的逻辑大小，并不表示文件里存着同样多的内容。因而 Size 非零与 Data() 返回错误并不矛盾。读取这类节时，应先看 Type，保留名称和大小等元数据，再把“没有文件内容”作为独立状态处理。

Go debug/elf 官方文档明确说明，NOBITS 的 Data 会报错，Open 得到的读取器也不能用来绕过这个限制。官方地址：https://pkg.go.dev/debug/elf。下面把旧的“遍历每个节并读完全部数据”代码迁移为有类型分支的读取器；这不是一次新版本不兼容变更介绍。

迁移范围是节读取器，不是 Go 版本升级

我会先修改读取结果的表达方式，再修改错误处理。如果结果只剩一个 []byte，调用者很难区分“正常空节”“没有文件内容”“读取失败”这三种情况。为每种情况都返回空切片，会让排障信息消失。

本文只分析自己生成、来源受信任的 ELF 文件，不加载执行其中的代码。debug/elf 并非针对恶意输入加固的通用安全解析器，示例的读取大小上限也不能代替独立的解析隔离。这里的代码和预期均为教学设计，没有本机执行或截图证据。

把 Size 与文件内容分开建模

ELF 节头提供 Name、Type、Size、Offset、Addr 等描述。NOBITS 可以有非零逻辑大小，但不占用对应的文件内容字节；其 Offset 不能被当成一块长度为 Size 的实际数据区域去读取。文件内容与装载后内存也属于不同观察对象。

.bss 是常见的 NOBITS 用途，其零初始化语义不等于 ELF 文件中包含同样长的零字节。真正的装载行为还涉及段和运行环境，不能靠对节逐个 make 零切片就声称重建了完整进程内存。

本篇的 sectionInfo 将逻辑大小 Size 与文件内容标识 FileData 分开，Bytes 只承载实际读取的内容。结果还保留 Type，便于调用者区分无内容的原因。

用按类型分支的读取器替换旧循环

package main

import (
    "debug/elf"
    "fmt"
    "log"
    "os"
)

// sectionInfo 保留逻辑大小，不把 NOBITS 当成读取失败。
type sectionInfo struct {
    Name     string
    Type     elf.SectionType
    Size     uint64
    FileData bool
    Bytes    []byte
}

// readSection 为普通节设置大小上限，NOBITS 只返回元数据。
func readSection(s *elf.Section, limit uint64) (sectionInfo, error) {
    if s == nil {
        return sectionInfo{}, fmt.Errorf("节不能为空")
    }
    info := sectionInfo{Name: s.Name, Type: s.Type, Size: s.Size}
    if s.Type == elf.SHT_NOBITS {
        // 没有文件内容，不读取，也不按逻辑大小分配全零切片。
        return info, nil
    }
    if s.Size > limit {
        return sectionInfo{}, fmt.Errorf("节 %q 超出读取上限: %d", s.Name, s.Size)
    }
    data, err := s.Data()
    if err != nil {
        return sectionInfo{}, fmt.Errorf("读取节 %q: %w", s.Name, err)
    }
    info.FileData = true
    info.Bytes = data
    return info, nil
}

func inspect(path string) (err error) {
    f, err := elf.Open(path)
    if err != nil {
        return err
    }
    defer func() {
        // 读取成功时也保留关闭文件的错误。
        if closeErr := f.Close(); err == nil {
            err = closeErr
        }
    }()
    const limit = uint64(8 

readSection 遇到 NOBITS 时只返回元数据，不调用 Data，也不根据 Size 分配切片。普通节超过上限返回错误；允许读取的普通节若 Data 失败，保留底层 error 并补充节名。

FileData 在本示例中表示已成功取得文件内容这一分支，而不是保证 Bytes 长度大于零。普通空节可以 FileData=true、长度为零；NOBITS 则 FileData=false。不要在上层再把二者压成一个 len(Bytes)==0 判断。

保存为 inspect.go，准备一个自己构建的 ELF 文件后，可由读者运行：

# 只读取受信任文件，不运行其内部程序
# trusted-app.elf 需要替换为实际的 ELF 构建产物
go run inspect.go trusted-app.elf

程序自身可在支持 Go 的环境编译，但目标必须是 ELF；将 macOS Mach-O 或 Windows PE 当作 ELF 传入会得到格式错误。目标没有 NOBITS 节时，也不会凭空产生演示行。

保留真正读取错误与资源边界

迁移代码的重点是缩小特殊处理范围。NOBITS 没有数据是格式语义，截断文件、解压失败或普通节读取错误则仍然是错误，不能统一吞掉。Open 对 NOBITS 同样不能读取文件数据，换成 io.ReadAll(s.Open()) 不是修复方案。

压缩节的 Data 返回解压后的内容，大小预算应考虑逻辑内容及解压开销。本文上限是读取策略的一部分，无法覆盖 ELF 打开和头部解析的全部资源消耗，也没有基准数据来宣称它防住了所有资源问题。

inspect 将每节结果立即使用，避免在一个总数组里长期保留全部 Bytes；但一节完整数据仍由 Data 读入内存。若业务只需要元数据，可以完全不调用 Data。资源关闭放在 inspect 的 defer 内，避免 main 中 log.Fatal 跳过尚未执行的 defer。

关闭错误仅在没有读取错误时成为返回错误；若业务需要同时报告读取和关闭错误，可以另行合并。本例选择保留主要读取失败，不把它覆盖成关闭失败。

迁移后应该覆盖哪些输入

读者迁移自有读取器时，可准备下表材料观察行为；这些是应覆盖的输入条件，不是已经通过的测试报告。

落地清单只有几个动作：先确定要分析的是文件还是内存；类型分支放在读取之前；结构体保留状态；调用者不吞普通错误；最后去掉为 NOBITS 自动补零的旧逻辑。这是应用代码迁移，不要求以升级 Go 来修复一个格式理解问题。

为什么不能只判断节名 .bss？

名字是命名线索，类型才表达本文需要识别的文件内容语义。读取器不应把全部规则绑定到某个常见名字。

NOBITS 的 Size 能用于统计逻辑大小吗？

可以作为对应节的逻辑大小信息保留，但不要直接把它加入“实际文件内容字节数”后声称是文件占用。还要明确统计口径与对齐等因素。

需要模拟零初始化怎么办？

这是另一个由调用者明确选择的内存建模任务，应设置独立预算并标注合成数据，不能把合成零内容当作从文件读取的原始内容。

参考：Go Section.Data、Go Section.Open、ELF 节头规范。