Newer versions of the Linux kernel have apparently made a change that breaks NaCl's hardware exception handling. This was reported here: https://github.com/golang/go/issues/23836 Linux has apparently changed the meaning of the REG_CSGSFS field of mcontext_t. The top 16 bits used to be unused (labelled as "__pad0" in a comment), but now they're used for the %ss register's value. NaCl unnecessarily copies the %cs, %gs and %fs values out of this field and back in, and in doing so it resets the top 16 bits (see https://chromium.googlesource.com/native_client/src/native_client/+/d52121fcfeda7666d69d9df4b9d7a17bac3b61ac/src/trusted/service_runtime/linux/nacl_signal_64.c). When NaCl returns from the signal handler with REG_CSGSFS reset, Linux generates another signal (this time with si_code==SI_KERNEL), which causes NaCl to terminate the process.
Mar 15 2018, Project Member
The following revision refers to this bug: https://chromium.googlesource.com/native_client/src/native_client.git/+/303fc9961cb4231aa9828218362914ee4e51d16a commit 303fc9961cb4231aa9828218362914ee4e51d16a Author: Andrew Bonventre <firstname.lastname@example.org> Date: Thu Mar 15 23:24:45 2018 x86-64 Linux: don't update segment registers using the sig_ctx In some cases, the linux kernel considers the values set in mctx->gregs[REG_CSGSFS] to be invalid, preventing it from resuming execution of the process after the rt_sigreturn syscall and sending the process a SIGSEGV with an SI_KERNEL code. Some NaCl tests are failing on Mac and arm-hw-perf trybots, so committing with "No-Try: True". Remail@example.com BUG= https://crbug.com/nativeclient/4403 No-Try: True Change-Id: I59726a7e8e7d898171a452433484a0502f93f647 Reviewed-on: https://chromium-review.googlesource.com/962675 Commit-Queue: Mark Seaborn <firstname.lastname@example.org> Reviewed-by: Mark Seaborn <email@example.com> [modify] https://crrev.com/303fc9961cb4231aa9828218362914ee4e51d16a/src/trusted/service_runtime/linux/nacl_signal_64.c
Mar 16 2018,
Issue chromium:821943 has been merged into this issue.
Mar 22 2018, Project Member
For the record, this was the commit in Linux that introduced this issue: "x86/signal/64: Re-add support for SS in the 64-bit signal context" https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git/+/6c25da5ad55d48c41b8909bc1f4e3cd5d85bb499 (That was also linked from issue chromium:821943 .)
Sign in to add a comment