Go Wiki: LinuxKernelSignalVectorBug

引言

如果您看到此页面是因为 Go 程序打印了类似这样的消息,

runtime: note: your Linux kernel may be buggy
runtime: note: see https://go-lang.org.cn/wiki/LinuxKernelSignalVectorBug
runtime: note: mlock workaround for kernel bug failed with errno <number>

那么您正在使用可能存在 bug 的 Linux 内核。此内核 bug 可能已导致您的 Go 程序内存损坏,并可能导致您的 Go 程序崩溃。

如果您明白程序崩溃的原因,则可以忽略此页面。

否则,此页面将解释内核 bug 是什么,并提供一个 C 程序,您可以使用它来检查您的内核是否存在此 bug。

Bug 描述

Linux 内核版本 5.2 中引入了一个 bug:如果向线程传递信号,并且传递信号需要将线程信号栈的页面置为无效,则在返回信号到程序时,AVX YMM 寄存器可能会损坏。如果程序正在执行使用 YMM 寄存器的函数,则该函数的行为可能不可预测。

此 bug 仅发生在具有 x86 处理器的系统上。此 bug 会影响用任何语言编写的程序。此 bug 仅影响接收信号的程序。在接收信号的程序中,此 bug 更可能影响使用备用信号栈的程序。此 bug 仅影响使用 YMM 寄存器的程序。特别是在 Go 程序中,此 bug 通常会导致内存损坏,因为 Go 程序主要使用 YMM 寄存器来实现将一个内存缓冲区复制到另一个缓冲区。

此 bug 已报告给 Linux 内核开发人员。它很快就被修复了。此 bug 修复未向 Linux 内核 5.2 系列回溯。此 bug 在 Linux 内核版本 5.3.15、5.4.2 和 5.5 及更高版本中已修复。

仅当内核使用 GCC 9 或更高版本编译时,此 bug 才存在。

此 bug 存在于 vanilla Linux 内核版本 5.2.x(无论 x 为何值)、5.3.0 到 5.3.14、以及 5.4.0 和 5.4.1 中。但是,许多使用这些内核版本的发行版实际上已经回溯了补丁(它非常小)。而且,一些发行版仍使用 GCC 8 编译其内核,在这种情况下,内核不存在此 bug。

换句话说,即使您的内核处于易受攻击的范围内,也有很大可能它不会受到此 bug 的影响。

Bug 测试

要测试您的内核是否存在此 bug,可以运行以下 C 程序(点击“详细信息”查看程序)。在存在 bug 的内核上,它将几乎立即失败。在没有 bug 的内核上,它将运行 60 秒然后以状态码 0 退出。

// Build with: gcc -pthread test.c
//
// This demonstrates an issue where AVX state becomes corrupted when a
// signal is delivered where the signal stack pages aren't faulted in.
//
// There appear to be three necessary ingredients, which are marked
// with "!!!" below:
//
// 1. A thread doing AVX operations using YMM registers.
//
// 2. A signal where the kernel must fault in stack pages to write the
//    signal context.
//
// 3. Context switches. Having a single task isn't sufficient.

##include <errno.h>
##include <signal.h>
##include <stdio.h>
##include <stdlib.h>
##include <string.h>
##include <unistd.h>
##include <pthread.h>
##include <sys/mman.h>
##include <sys/prctl.h>
##include <sys/wait.h>

static int sigs;

static stack_t altstack;
static pthread_t tid;

static void die(const char* msg, int err) {
  if (err != 0) {
    fprintf(stderr, "%s: %s\n", msg, strerror(err));
  } else {
    fprintf(stderr, "%s\n", msg);
  }
  exit(EXIT_FAILURE);
}

void handler(int sig __attribute__((unused)),
             siginfo_t* info __attribute__((unused)),
             void* context __attribute__((unused))) {
  sigs++;
}

void* sender(void *arg) {
  int err;

  for (;;) {
    usleep(100);
    err = pthread_kill(tid, SIGWINCH);
    if (err != 0)
      die("pthread_kill", err);
  }
  return NULL;
}

void dump(const char *label, unsigned char *data) {
  printf("%s =", label);
  for (int i = 0; i < 32; i++)
    printf(" %02x", data[i]);
  printf("\n");
}

void doAVX(void) {
  unsigned char input[32];
  unsigned char output[32];

  // Set input to a known pattern.
  for (int i = 0; i < sizeof input; i++)
    input[i] = i;
  // Mix our PID in so we detect cross-process leakage, though this
  // doesn't appear to be what's happening.
  pid_t pid = getpid();
  memcpy(input, &pid, sizeof pid);

  while (1) {
    for (int i = 0; i < 1000; i++) {
      // !!! Do some computation we can check using YMM registers.
      asm volatile(
        "vmovdqu %1, %%ymm0;"
        "vmovdqa %%ymm0, %%ymm1;"
        "vmovdqa %%ymm1, %%ymm2;"
        "vmovdqa %%ymm2, %%ymm3;"
        "vmovdqu %%ymm3, %0;"
        : "=m" (output)
        : "m" (input)
        : "memory", "ymm0", "ymm1", "ymm2", "ymm3");
      // Check that input == output.
      if (memcmp(input, output, sizeof input) != 0) {
        dump("input ", input);
        dump("output", output);
        die("mismatch", 0);
      }
    }

    // !!! Release the pages of the signal stack. This is necessary
    // because the error happens when copy_fpstate_to_sigframe enters
    // the failure path that handles faulting in the stack pages.
    // (mmap with MMAP_FIXED also works.)
    //
    // (We do this here to ensure it doesn't race with the signal
    // itself.)
    if (madvise(altstack.ss_sp, altstack.ss_size, MADV_DONTNEED) != 0)
      die("madvise", errno);
  }
}

void doTest() {
  // Create an alternate signal stack so we can release its pages.
  void *altSigstack = mmap(NULL, SIGSTKSZ, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
  if (altSigstack == MAP_FAILED)
    die("mmap failed", errno);
  altstack.ss_sp = altSigstack;
  altstack.ss_size = SIGSTKSZ;
  if (sigaltstack(&altstack, NULL) < 0)
    die("sigaltstack", errno);

  // Install SIGWINCH handler.
  struct sigaction sa = {
    .sa_sigaction = handler,
    .sa_flags = SA_ONSTACK | SA_RESTART,
  };
  sigfillset(&sa.sa_mask);
  if (sigaction(SIGWINCH, &sa, NULL) < 0)
    die("sigaction", errno);

  // Start thread to send SIGWINCH.
  int err;
  pthread_t ctid;
  tid = pthread_self();
  if ((err = pthread_create(&ctid, NULL, sender, NULL)) != 0)
    die("pthread_create sender", err);

  // Run test.
  doAVX();
}

void *exiter(void *arg) {
  sleep(60);
  exit(0);
}

int main() {
  int err;
  pthread_t ctid;

  // !!! We need several processes to cause context switches. Threads
  // probably also work. I don't know if the other tasks also need to
  // be doing AVX operations, but here we do.
  int nproc = sysconf(_SC_NPROCESSORS_ONLN);
  for (int i = 0; i < 2 * nproc; i++) {
    pid_t child = fork();
    if (child < 0) {
      die("fork failed", errno);
    } else if (child == 0) {
      // Exit if the parent dies.
      prctl(PR_SET_PDEATHSIG, SIGKILL, 0, 0, 0);
      doTest();
    }
  }

  // Exit after a while.
  if ((err = pthread_create(&ctid, NULL, exiter, NULL)) != 0)
    die("pthread_create exiter", err);

  // Wait for a failure.
  int status;
  if (wait(&status) < 0)
    die("wait", errno);
  if (status == 0)
    die("child unexpectedly exited with success", 0);
  fprintf(stderr, "child process failed\n");
  exit(1);
}

操作方法

如果您的内核版本处于可能存在此 bug 的范围内,请运行上面的 C 程序以查看它是否失败。如果失败,则您的内核存在 bug。您应该升级到较新的内核。此 bug 没有解决办法。

使用 1.14 构建的 Go 程序将尝试通过使用 mlock 系统调用将信号栈页面锁定在内存中来缓解此 bug。这是有效的,因为 bug 仅在信号栈页面需要被置为无效时才会发生。但是,此 mlock 用法可能会失败。如果您看到消息

runtime: note: mlock workaround for kernel bug failed with errno 12

errno 12(也称为 ENOMEM)表示 mlock 失败,因为系统设置了程序可以锁定的内存量限制。如果您可以增加限制,程序可能会成功。这可以使用 ulimit -l 完成。在 Docker 容器中运行程序时,可以通过调用 docker 并带上选项 -ulimit memlock=67108864 来增加限制。

如果无法增加 mlock 限制,那么您可以通过在运行 Go 程序时设置环境变量 GODEBUG=asyncpreemptoff=1 来降低此 bug 干扰程序的可能性。但是,这只会降低您的程序遭受内存损坏的可能性(因为它减少了您的程序将接收的信号数量)。bug 仍然存在,内存损坏仍可能发生。

问题?

请在邮件列表 golang-nuts@googlegroups.com 或任何 Go 论坛(如 Questions 中所述)上提问。

详细信息

要查看有关此 bug 如何影响 Go 程序以及如何检测和理解它的更多详细信息,请参见 #35777#35326


此内容是 Go Wiki 的一部分。