用 runtime/secret 降低内存转储中的密钥暴露

runtime/secret 能降低内存转储里的密钥暴露，但它不是“让密钥永远无法被 dump”。它真正改变的是秘密材料的残留时间：secret.Do 包住的调用树结束后，运行时会及时擦除该调用树使用过的寄存器和栈；堆分配则在对象不可达并被垃圾收集器发现后擦除。

Go 官方文档：https://pkg.go.dev/runtime/secret

把密钥加载、密码学计算和临时缓冲区限制在最小的 secret.Do 调用树内，可以减少“计算早已结束，但旧密钥仍留在可转储内存中”的窗口。转储发生在计算期间、密钥存在于调用方或全局变量中、平台不受支持时，仍然可能暴露。

变化不在转储工具，而在秘密的残留时间

Go 的 core dump 面向进程状态，heap dump 则记录堆对象、goroutine、终结器等运行时信息。两类转储都是排障工具，也都可能把当时仍驻留内存的秘密材料带进文件。runtime/secret 不会拦截转储命令，也不会过滤转储文件；它做的是让已经用完的临时数据更早离开可恢复的内存区域。

这个区别决定了正确预期。若转储正好发生在 HMAC、签名或密钥派生正在运行时，算法必然需要使用明文材料，secret.Do 无法让正在使用的秘密消失。它主要降低后续转储看到历史残留的机会，而不是消灭运行时取证风险。

secret.Do 为什么能缩小暴露面

官方文档给出的行为可以压缩成三条。

• 寄存器：受保护调用树使用过的寄存器会在 Do 返回前擦除。
• 栈：调用树使用过的栈空间会在 Do 返回前擦除。
• 堆：调用树中的堆分配必须先变得不可达，再等垃圾收集器发现，之后才会被擦除。

因此，最合适的对象是寿命很短的密码学中间态：解包后的数据密钥、固定大小的工作缓冲区、哈希或 AEAD 内部状态。越少扩容、越少把引用传出闭包，秘密越容易随调用树一起收束。

这个包目前仍是实验能力，不受 Go 1 兼容承诺约束，并且只有设置 GOEXPERIMENT=runtimesecret 时才存在。官方目前只声明 linux/amd64 和 linux/arm64 支持擦除；其他平台上的 Do 只是直接调用传入函数。

# 构建和测试必须使用相同的实验开关，避免测试环境与发布产物不一致
GOEXPERIMENT=runtimesecret go test ./...
GOEXPERIMENT=runtimesecret go build ./cmd/service

最小写法：让密钥在 Do 内产生并使用

下面的示例让密钥加载器把数据写入 secret.Do 内部的固定数组，HMAC 结果则复制到调用方预先分配的数组。这样，秘密缓冲区和哈希状态属于受保护调用树，非秘密摘要可以正常返回。

package securemac

import (
    "crypto/hmac"
    "crypto/sha256"
    "errors"
    "runtime/secret"
)

var ErrLoadKey = errors.New("load key failed")

type KeyLoader func(dst []byte) (int, error)

func Sign(load KeyLoader, message []byte) ([sha256.Size]byte, error) {
    // 结果不是秘密，并且在受保护调用树外预先分配。
    var signature [sha256.Size]byte
    var opErr error

    secret.Do(func() {
        // 固定数组限制扩容，函数返回后其栈空间由运行时擦除。
        var key [64]byte
        n, err := load(key[:])
        if err != nil || n  len(key) {
            // 不把加载器错误原文带出，避免错误对象引用敏感上下文。
            opErr = ErrLoadKey
            return
        }

        // 密钥切片、HMAC 状态和临时摘要都留在 secret.Do 调用树内。
        mac := hmac.New(sha256.New, key[:n])
        _, _ = mac.Write(message)
        copy(signature[:], mac.Sum(nil))
    })

    return signature, opErr
}

关键不只是“套一层闭包”，而是密钥在哪里产生。若调用方先创建 key := []byte(...)，再把它传进 secret.Do，调用方仍然持有原始切片；擦除调用树里的临时状态，不等于擦除那个外部副本。更稳妥的做法是让加载器在闭包内填充固定缓冲区，并避免把底层数组缓存到其他地方。

四类副本不会因为 Do 返回而自动消失

子 goroutine 也需要谨慎。官方说明，在受保护调用树中启动的 goroutine 会表现得像自身也包在 Do 中，但把密钥发送给已经存在的后台工作器，会形成另一条生命周期。不要仅凭“代码最初在闭包里”就认定所有接收方都处于相同边界。

对旧代码的影响：先改密钥路径，再加运行时边界

已有服务常见的形态是启动时从环境变量或配置文件读取密钥，然后存进包级变量。直接在每次加密操作外加 secret.Do，只能保护算法内部新产生的临时状态，包级变量仍然长时间驻留。迁移时应先把“全局明文值”改成“按需加载或短期解包”，再把真正使用密钥的调用树包起来。

一条更清晰的密钥路径包含三个边界：

• 外部密钥源：KMS、HSM、文件描述符或其他受控来源负责保存、授权与轮换。
• 受保护计算：加载器、固定密钥缓冲区和密码学状态位于 secret.Do 调用树内。
• 非秘密输出：摘要、签名或密文由调用方预先分配并接收，错误只返回固定类别。

这并不意味着外部密钥系统会自动清理 Go 进程内存，也不意味着 runtime/secret 能代替权限、轮换和审计。两者分别管理“密钥从哪里来”和“密钥在进程里用完后多久消失”。

最小核对：确认能力真的处于启用状态

secret.Enabled() 报告当前 goroutine 是否处于 secret 模式。它适合做调用边界断言，但不能证明某个转储文件不含秘密，也不能替代平台和构建检查。

func useProtectedPath() {
    secret.Do(func() {
        // 这里只核对当前 goroutine 的模式，不打印任何密钥或缓冲区。
        if !secret.Enabled() {
            panic("runtime secret mode is not enabled")
        }

        // 在这里调用只处理短生命周期秘密的函数。
        runCryptoOperation()
    })
}

采用前至少确认以下事项：

• 构建和测试都显式设置了 GOEXPERIMENT=runtimesecret。
• 生产目标是官方支持的 linux/amd64 或 linux/arm64。
• 密钥不会先进入全局变量、日志、指标标签或长期缓存。
• Do 内限制了切片和 map 扩容，并评估额外堆擦除带来的 GC 成本。
• core dump、heap dump 和崩溃文件仍按敏感资产管理，设置最小权限、保留期和删除策略。
• 团队接受实验 API 未来可能变化，并固定工具链版本和回滚方案。

常见问题

用了 runtime/secret，core dump 就安全了吗？

不能这样保证。它缩短已用秘密在寄存器、栈和部分堆分配中的残留时间，但转储发生在计算期间，或密钥还存在于调用方、全局变量和其他副本中时，仍可能暴露。

heap dump 还能看到 Do 内产生的密钥吗？

取决于时点。仍可达的堆对象会被保留；对象不可达后也要等 GC 发现并完成相应擦除。Do 返回不代表所有堆字节在同一时刻清零。

为什么不直接对 key 切片手动清零？

手动清零只能处理你明确持有的那个缓冲区，编译器、调用栈、寄存器和库内部可能还有临时副本。runtime/secret 的价值在于让运行时参与调用树的清理，但两种方式都不能治理边界外副本。

macOS 开发机能验证擦除效果吗？

当前官方只声明支持 Linux 的 amd64 和 arm64。不支持的平台上 Do 会直接调用函数，因此开发机能编译或执行 API，并不等于获得同样的擦除保护。

哪些场景最值得优先尝试？

短时解包数据密钥、签名、MAC、密钥派生等调用边界清晰、明文寿命短且部署在受支持 Linux 架构上的场景更适合。长期全局缓存密钥的服务应先重构数据路径。

结论

runtime/secret 的正确定位是内存卫生加固：它让密码学调用结束后的寄存器和栈更快被擦除，并为失去引用的堆分配安排擦除，从而减少后续转储捞到历史密钥的机会。要让这层保护真正有效，必须同时限制调用方副本、全局状态、堆引用和错误路径，并继续把所有转储文件当作高敏感资产。