Use a per-task stack canary for stack protector

[kees]

Some architectures don't have compiler support for a per-task stack canary, so the canary value is the same across all kernel threads. This means a stack memory exposure of the canary value from one task can be used for attacks against all other kernel tasks, making such exposures much more severe. To avoid this, the stack canary must be different for each kernel thread, which requires compiler support as well as kernel support.

Recent implementations use the compiler arguments similar to the form -mstack-protector-guard=sysreg -mstack-protector-guard-reg=$REGISTER -mstack-protector-guard-offset=$OFFSET (see implementations below).

• Linux/compiler/architecture support matrix

  • x86_64: old %gs-offset #170
    • gcc: implemented
    • clang: implemented
  • x86_32: -mstack-protector-guard-reg=fs -mstack-protector-guard-symbol=__stack_chk_guard, or old %gs offset before v5.13
    • gcc: implemented
    • clang: implemented
  • arm64: -mstack-protector-guard=sysreg -mstack-protector-guard-reg=sp_el0 -mstack-protector-guard-offset=0
    • gcc: implemented
    • clang: implemented
  • arm32: GCC plugin
    • gcc: bug, plugin
    • clang: needed
  • powerpc: -mstack-protector-guard=tls -mstack-protector-guard-reg=r2 (32-bit) or r13 (64-bit)
    • gcc: implemented
    • clang: needed
  • riscv64: -mstack-protector-guard=tls -mstack-protector-guard-reg=tp -mstack-protector-guard-offset=0
    • gcc: implemented
    • clang: bug
  • s390: (no stack protector support at all)
  • mips: only global canary

• Implementation weaknesses

  • canary is leaked via register contents
    • x86_32
      • gcc
      • clang: open bug
    • x86_64
      • gcc
      • clang: open bug
    • arm32
      • gcc: fixed
      • clang: open bug
    • arm64
      • gcc: fixed
      • clang: open bug

[kees]

arm64 background:
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-January/554802.html

arm64 compiler changes:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=359c1bf35e3109d2f3882980b47a5eae46123259

arm64 kernel implementation:
https://git.kernel.org/linus/0a1213fa7432778b71a1c0166bf56660a3aab030

[kees]

Clang support needed:
https://bugs.llvm.org/show_bug.cgi?id=47341

[kees]

GCC support for RISCV proposed:
https://marc.info/?l=gcc-patches&m=159462831728667&w=2

[kees]

(I'm removing the "fixed" labels for arm32 and arm64 since there isn't Clang support yet...)

[tsautereau-anssi]

(I'm removing the "fixed" labels for arm32 and arm64 since there isn't Clang support yet...)

PowerPC isn't supported either in Clang, is it?

By the way, RISC-V support for -mstack-protector-guard landed in GCC on July.

[kees]

Hm, I may need to split up the per-arch issues and per-compiler issues into separate bugs. Or a task list, perhaps.

[kees]

Okay, I've tried to collect the matrix in the bug description.

[kees]

https://git.kernel.org/linus/fea2fed201ee5647699018a56fbb6a5e8cc053a5 in v5.12 (riscv per-task canary support for gcc)

[kees]

Also tracked at ClangBuiltLinux#289

[kees]

Implemented in Clang for arm64 now: llvm/llvm-project@0f41778

[tsautereau-anssi]

Implemented in Clang for arm64 now: llvm/llvm-project@0f41778

I think there's a leak of the canary though: llvm/llvm-project#46338 (originally https://bugs.llvm.org/show_bug.cgi?id=50467)

[kees]

Thanks for the heads-up!

[nickdesaulniers]

I just accepted https://reviews.llvm.org/D129346 which should close out llvm/llvm-project#48553. Therefor, I have marked

x86_32: -mstack-protector-guard-reg=fs -mstack-protector-guard-symbol=__stack_chk_guard, or old %gs offset before v5.13
gcc: implemented
clang: implemented

[keith-packard]

llvm/llvm-project#46685 has been closed

[nathanchance]

clang support for PowerPC was merged in llvm/llvm-project@44b020a (20.0.0) and the kernel was updated to support clang’s implementation with my changes in the 6.13 pull request.