Linux内核中的stack protector实现

Linux 内核中的 Stack Protector（也称为 Stack Canary）是一种重要的安全机制，旨在检测和防御栈缓冲区溢出攻击。其核心思想是在函数栈帧的关键位置（通常是返回地址之前）放置一个特殊的、难以预测的值（称为 “canary”），并在函数返回前检查该值是否被意外或恶意修改。如果值被改变，内核会认为发生了栈破坏并立即崩溃（触发 kernel panic），从而阻止攻击者利用溢出控制程序执行流（例如执行任意代码或进行 ROP 攻击）。

以下是 Linux 内核中 Stack Protector 实现的关键细节：

  1. Canary 的生成与存储：

    • 引导早期初始化： 内核在启动的非常早期阶段（在 start_kernel 函数中，由 boot_init_stack_canary 函数执行）生成一个全局的、随机的 “主” canary 值。这个随机性对于安全性至关重要，使得攻击者难以预测 canary 的值。
    • Per-Task Canary： 为了提高安全性（防止通过信息泄露获取一个任务的 canary 去攻击另一个任务），每个进程（任务）在创建时（fork 或创建内核线程时）会获得一个基于主 canary 和任务特定信息（如进程 ID）派生出的唯一 canary 值。这个值存储在进程的 task_struct 结构体中（通常是 stack_canary 字段）。
    • x86 架构的特殊处理 (FS/GS 寄存器)：
      • 在 x86-64 架构上，内核利用 GS 寄存器的段基址来高效地访问当前任务的 task_struct。
      • 内核配置 GS 基址指向当前 CPU 的 struct pcpu_hot，该结构内部包含指向当前运行任务 task_struct 的指针。
      • 当需要访问当前任务的 canary（例如在函数序言/尾声）时，编译器生成的代码会通过 GS 寄存器进行偏移寻址，快速定位到 task_struct->stack_canary。

  2. 函数编译时的插桩：

    • 启用了 Stack Protector 的内核在编译时，会对选定的函数使用 GCC 的 -fstack-protector-strong（或历史上使用过的 -fstack-protector）编译选项。
    • 函数序言 (Prologue)： 在函数开始时，编译器插入指令将当前任务的 canary 值（从 task_struct->stack_canary 获取）压入（或存储到）当前函数栈帧中的一个特定位置（通常紧邻着局部变量之后，但在保存的帧指针和返回地址之前）。
    • 函数尾声 (Epilogue)： 在函数返回（通过 ret 指令）之前，编译器插入指令将栈上保存的 canary 值重新读出，并与存储在 task_struct->stack_canary 中的原始值进行比较。
      • 匹配： 如果值匹配，函数正常返回。
      • 不匹配： 如果值不匹配（说明栈上该位置到返回地址之间的数据，包括 canary 本身，可能被溢出覆盖了），则触发一个预定义的错误处理函数 __stack_chk_fail。

  3. __stack_chk_fail 处理：

    • 这个函数在内核中实现。
    • 它的核心操作是调用 panic 函数，导致内核立即崩溃，并打印出类似 "Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: [function_name]" 的错误信息。
    • 这种崩溃是主动的安全防御措施，目的是在检测到栈破坏时立即终止系统运行，防止潜在的进一步利用。

  4. 中断栈的 Canary：

    • 内核不仅保护进程的内核栈，也保护中断栈。
    • 在中断/异常处理程序的入口点（例如 entry_64.S 中的汇编代码），内核会加载一个特定的 canary 值到中断栈上。
    • 在退出中断处理程序返回到被中断的上下文之前，会检查这个中断栈上的 canary 值是否被破坏。
    • 如果中断栈 canary 被破坏，同样会触发 panic。

  5. 哪些函数受到保护？

    • 早期可能只保护包含字符数组的函数。现在主要使用 -fstack-protector-strong，其规则更智能：
      • 保护包含任意大小的字符数组的函数。
      • 保护包含大于等于 8 字节的其他类型数组的函数。
      • 保护包含地址被取用的局部变量的函数（因为这可能暗示该变量被传递到可能进行越界写入的函数）。
    • 明确标记为 __no_stack_protector 的函数会被排除。
    • 非常关键、性能敏感或需要在堆栈保护机制初始化之前运行的极早期代码可能不受保护或使用特殊处理。

  6. 配置选项：

    • CONFIG_STACKPROTECTOR (或旧版本中的 CONFIG_CC_STACKPROTECTOR): 基本启用 Stack Protector (通常是 -fstack-protector，保护规则相对简单)。
    • CONFIG_STACKPROTECTOR_STRONG: 启用更强的保护 (-fstack-protector-strong)，保护更多的函数。这是现代内核的推荐和默认选择。
    • CONFIG_STACKPROTECTOR_PER_TASK: 启用 per-task canary (这是默认且必要的)。
    • CONFIG_CC_STACKPROTECTOR_NONE: 完全禁用 Stack Protector（不推荐，除非有特殊原因且了解风险）。

总结与重要性：

Linux 内核的 Stack Protector 是一种经过精心设计、高效且基本成为标配的漏洞利用缓解技术（Exploit Mitigation）。它通过：

  1. 在编译时插桩关键函数。
  2. 使用随机化的、per-task 的 canary 值。
  3. 在函数返回前验证 canary。
  4. **在检测到破坏时立即崩溃内核 (panic)**。

极大地增加了攻击者成功利用内核栈缓冲区溢出漏洞的难度。攻击者不仅需要触发漏洞覆盖返回地址，还需要精确地覆盖 canary 位置为其原始值（而原始值是随机的且对每个任务唯一），否则攻击会被立即检测并终止。这使得许多传统的栈溢出攻击手法失效。

局限性：

  • 无法防御堆溢出、格式化字符串漏洞、逻辑漏洞等。
  • 无法防御能精确泄露 canary 值的信息泄露漏洞。一旦 canary 被泄露，攻击者可以构造 payload 时包含正确的 canary 从而绕过保护（这就是 per-task canary 和 KASLR 等缓解措施的重要性）。
  • 无法防御不覆盖 canary 的栈破坏（例如直接修改保存的帧指针）。
  • 对性能有轻微开销（存储和检查 canary 的指令）。

尽管如此，Stack Protector 仍然是 Linux 内核纵深防御策略中极其重要且有效的一环。一个著名的成功案例是它阻止了利用 CVE-2017-1000367 (Stack Clash) 在内核中的实际利用。