From: ndesaulniers@google.com To: "Borislav Petkov (AMD)" <bp@alien8.de> Cc: Peter Zijlstra <peterz@infradead.org>, Josh Poimboeuf <jpoimboe@kernel.org>, x86@kernel.org, Michael Ellerman <mpe@ellerman.id.au>, Nicholas Piggin <npiggin@gmail.com>, Christophe Leroy <christophe.leroy@csgroup.eu>, Miguel Ojeda <ojeda@kernel.org>, Nathan Chancellor <nathan@kernel.org>, Tom Rix <trix@redhat.com>, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev, Nick Desaulniers <ndesaulniers@google.com> Subject: [PATCH 0/2] start_kernel: omit stack canary Date: Mon, 17 Apr 2023 14:54:06 -0700 [thread overview] Message-ID: <20230412-no_stackp-v1-0-86d2034a4d06@google.com> (raw) A security research paper was recently published detailing Catch Handler Oriented Programming (CHOP) attacks. https://download.vusec.net/papers/chop_ndss23.pdf The TL;DR being that C++ structured exception handling runtimes are attractive gadgets for Jump Oriented Programming (JOP) attacks. In response to this, a mitigation was developed under embargo in clang-16 to check the stack canary before calling noreturn functions. https://bugs.chromium.org/p/llvm/issues/detail?id=30 This started causing boot failures in Android kernel trees downstream of stable linux-4.14.y that had proto-LTO support, as reported by Nathan Chancellor. https://github.com/ClangBuiltLinux/linux/issues/1815 Josh Poimboeuf recently sent a series to explicitly annotate more functions as noreturn. Nathan noticed the series, and tested it finding that it now caused boot failures with clang-16+ on mainline (raising the visibility and urgency of the issue). https://lore.kernel.org/cover.1680912057.git.jpoimboe@kernel.org/ V2 of this series is rebased on tip/objtool/core @ 88b478ee5c7b080b70c68d6e9b3da6c2b518ceb0 now that that series has been picked up. Once the embargo was lifted, I asked questions such as "what does C++ structured exception handling have to do with C code" and "surely GCC didn't ship the same mitigation for C code (narrator: 'They did not: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a25982ada523689c8745d7fb4b1b93c8f5dab2e7')?" I now have a patch out for LLVM to undo this mess (or at least limit it to C++ functions that may throw, similar to GCC's mitigation); it hasn't landed yet but we're close to consensus and I expect it to land imminently. https://reviews.llvm.org/D147975 Remember this thread? (Pepperidge farms remembers...) https://lore.kernel.org/all/20200314164451.346497-1-slyfox@gentoo.org/ That reminded me that years ago we discussed a function attribute for no_stack_protector. https://lore.kernel.org/all/20200316130414.GC12561@hirez.programming.kicks-ass.net/ GCC didn't have one at the time, it now does. In addition to the LLVM fix, I'd like to introduce this in the kernel so that we might start using it in additional places: * https://lore.kernel.org/linux-pm/20200915172658.1432732-1-rkir@google.com/ * https://lore.kernel.org/lkml/20200918201436.2932360-30-samitolvanen@google.com/ And eventually remove the final macro expansion site of prevent_tail_call_optimization. With the LLVM fix, this series isn't required, but I'd like to start paving the way to use these function attributes since I think they are a sweet spot in terms of granularity (as opposed to trying to move start_kernel to its own TU compiled with -fno-stack-protector). Changes V1 -> V2: * Rebase to avoid conflicts with Josh's changes. * Fix comment style as per Peter. * Pick up tags. Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> --- Nick Desaulniers (2): start_kernel: add no_stack_protector fn attr start_kernel: omit prevent_tail_call_optimization for newer toolchains arch/powerpc/kernel/smp.c | 1 + include/linux/compiler_attributes.h | 12 ++++++++++++ init/main.c | 9 ++++++++- 3 files changed, 21 insertions(+), 1 deletion(-) --- base-commit: 88b478ee5c7b080b70c68d6e9b3da6c2b518ceb0 change-id: 20230412-no_stackp-a98168a2bb0a Best regards, -- Nick Desaulniers <ndesaulniers@google.com>
WARNING: multiple messages have this Message-ID (diff)
From: ndesaulniers@google.com To: "Borislav Petkov (AMD)" <bp@alien8.de> Cc: llvm@lists.linux.dev, Peter Zijlstra <peterz@infradead.org>, x86@kernel.org, Nick Desaulniers <ndesaulniers@google.com>, linux-kernel@vger.kernel.org, Nathan Chancellor <nathan@kernel.org>, Nicholas Piggin <npiggin@gmail.com>, Tom Rix <trix@redhat.com>, Miguel Ojeda <ojeda@kernel.org>, linuxppc-dev@lists.ozlabs.org, Josh Poimboeuf <jpoimboe@kernel.org> Subject: [PATCH 0/2] start_kernel: omit stack canary Date: Mon, 17 Apr 2023 14:54:06 -0700 [thread overview] Message-ID: <20230412-no_stackp-v1-0-86d2034a4d06@google.com> (raw) A security research paper was recently published detailing Catch Handler Oriented Programming (CHOP) attacks. https://download.vusec.net/papers/chop_ndss23.pdf The TL;DR being that C++ structured exception handling runtimes are attractive gadgets for Jump Oriented Programming (JOP) attacks. In response to this, a mitigation was developed under embargo in clang-16 to check the stack canary before calling noreturn functions. https://bugs.chromium.org/p/llvm/issues/detail?id=30 This started causing boot failures in Android kernel trees downstream of stable linux-4.14.y that had proto-LTO support, as reported by Nathan Chancellor. https://github.com/ClangBuiltLinux/linux/issues/1815 Josh Poimboeuf recently sent a series to explicitly annotate more functions as noreturn. Nathan noticed the series, and tested it finding that it now caused boot failures with clang-16+ on mainline (raising the visibility and urgency of the issue). https://lore.kernel.org/cover.1680912057.git.jpoimboe@kernel.org/ V2 of this series is rebased on tip/objtool/core @ 88b478ee5c7b080b70c68d6e9b3da6c2b518ceb0 now that that series has been picked up. Once the embargo was lifted, I asked questions such as "what does C++ structured exception handling have to do with C code" and "surely GCC didn't ship the same mitigation for C code (narrator: 'They did not: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a25982ada523689c8745d7fb4b1b93c8f5dab2e7')?" I now have a patch out for LLVM to undo this mess (or at least limit it to C++ functions that may throw, similar to GCC's mitigation); it hasn't landed yet but we're close to consensus and I expect it to land imminently. https://reviews.llvm.org/D147975 Remember this thread? (Pepperidge farms remembers...) https://lore.kernel.org/all/20200314164451.346497-1-slyfox@gentoo.org/ That reminded me that years ago we discussed a function attribute for no_stack_protector. https://lore.kernel.org/all/20200316130414.GC12561@hirez.programming.kicks-ass.net/ GCC didn't have one at the time, it now does. In addition to the LLVM fix, I'd like to introduce this in the kernel so that we might start using it in additional places: * https://lore.kernel.org/linux-pm/20200915172658.1432732-1-rkir@google.com/ * https://lore.kernel.org/lkml/20200918201436.2932360-30-samitolvanen@google.com/ And eventually remove the final macro expansion site of prevent_tail_call_optimization. With the LLVM fix, this series isn't required, but I'd like to start paving the way to use these function attributes since I think they are a sweet spot in terms of granularity (as opposed to trying to move start_kernel to its own TU compiled with -fno-stack-protector). Changes V1 -> V2: * Rebase to avoid conflicts with Josh's changes. * Fix comment style as per Peter. * Pick up tags. Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> --- Nick Desaulniers (2): start_kernel: add no_stack_protector fn attr start_kernel: omit prevent_tail_call_optimization for newer toolchains arch/powerpc/kernel/smp.c | 1 + include/linux/compiler_attributes.h | 12 ++++++++++++ init/main.c | 9 ++++++++- 3 files changed, 21 insertions(+), 1 deletion(-) --- base-commit: 88b478ee5c7b080b70c68d6e9b3da6c2b518ceb0 change-id: 20230412-no_stackp-a98168a2bb0a Best regards, -- Nick Desaulniers <ndesaulniers@google.com>
next reply other threads:[~2023-04-17 21:54 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-04-17 21:54 ndesaulniers [this message] 2023-04-17 21:54 ` [PATCH 0/2] start_kernel: omit stack canary ndesaulniers 2023-04-17 21:54 ` [PATCH 1/2] start_kernel: add no_stack_protector fn attr ndesaulniers 2023-04-17 21:54 ` ndesaulniers 2023-04-17 21:54 ` [PATCH 2/2] start_kernel: omit prevent_tail_call_optimization for newer toolchains ndesaulniers 2023-04-17 21:54 ` ndesaulniers -- strict thread matches above, loose matches on Subject: below -- 2023-04-12 18:32 [PATCH 0/2] start_kernel: omit stack canary ndesaulniers 2023-04-12 18:32 ` ndesaulniers 2023-04-13 7:51 ` Peter Zijlstra 2023-04-13 7:51 ` Peter Zijlstra
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20230412-no_stackp-v1-0-86d2034a4d06@google.com \ --to=ndesaulniers@google.com \ --cc=bp@alien8.de \ --cc=christophe.leroy@csgroup.eu \ --cc=jpoimboe@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=llvm@lists.linux.dev \ --cc=mpe@ellerman.id.au \ --cc=nathan@kernel.org \ --cc=npiggin@gmail.com \ --cc=ojeda@kernel.org \ --cc=peterz@infradead.org \ --cc=trix@redhat.com \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.