From: Nick Desaulniers <ndesaulniers@google.com> To: Dan Li <ashimida@linux.alibaba.com> Cc: masahiroy@kernel.org, michal.lkml@markovi.net, catalin.marinas@arm.com, will@kernel.org, keescook@chromium.org, nathan@kernel.org, tglx@linutronix.de, akpm@linux-foundation.org, samitolvanen@google.com, frederic@kernel.org, rppt@kernel.org, mark.rutland@arm.com, yifeifz2@illinois.edu, rostedt@goodmis.org, viresh.kumar@linaro.org, andreyknvl@gmail.com, colin.king@canonical.com, ojeda@kernel.org, luc.vanoostenryck@gmail.com, elver@google.com, nivedita@alum.mit.edu, ardb@kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-hardening@vger.kernel.org, clang-built-linux@googlegroups.com Subject: Re: [PATCH] [PATCH V4]ARM64: SCS: Add gcc plugin to support Shadow Call Stack Date: Fri, 15 Oct 2021 12:13:33 -0700 [thread overview] Message-ID: <CAKwvOdnMvBP-1=YbXTpYOgWqCBy44tUvWdtMXp8p485bYnPYNQ@mail.gmail.com> (raw) In-Reply-To: <722d9662-e27c-2efb-e8cf-d505b6950475@linux.alibaba.com> On Fri, Oct 15, 2021 at 11:29 AM Dan Li <ashimida@linux.alibaba.com> wrote: > > > > On 10/15/21 2:44 AM, Nick Desaulniers wrote: > > On Wed, Oct 13, 2021 at 4:28 PM Dan Li <ashimida@linux.alibaba.com> wrote: > >> --- a/include/linux/compiler-gcc.h > >> +++ b/include/linux/compiler-gcc.h > >> @@ -50,6 +50,10 @@ > >> #define __latent_entropy __attribute__((latent_entropy)) > >> #endif > >> > >> +#if defined(SHADOW_CALL_STACK_PLUGIN) && !defined(__CHECKER__) > >> +#define __noscs __attribute__((no_shadow_call_stack)) > >> +#endif > > > > Cool this is a nice addition, and something I don't think that clang > > has. For any new feature, having a function attribute to disable it > > at the function granularity is nice, and plays better with LTO than -f > > group flags. Though that begs the question: what happens if a __noscs > > callee is inlined into a non-__noscs caller, or vice versa? > Thanks Nick, > > According to my understanding, all inline optimizations in gcc should > happen before inserting scs insns (scs and paciasp/autiasp use the > same insertion point). Therefore, the check for the __noscs attribute > will also occur after all inlining is completed. > > As in the following example: > - Since __noscs attribute is specified, scs_test1 does not insert scs insns > - Since normal functions scs_test2/3 uses x30, it needs to insert scs insns > - Since __noscs attribute is specified, scs_test4 after inlining does not > need to insert scs insns > > __always_inline __noscs void scs_test1(void) > { > asm volatile("mov x1, x1\n\t":::"x30"); > } > > //scs insns inserted after function inline > void scs_test2(void) > { > scs_test1(); > } That may be surprising to developers. Perhaps __always_inline on scs_test1 is distracting this test case, but I suspect it may not make a difference. This particular issue comes up time and again with stack protectors; ie. the callee is marked no stack protector, then gets inlined into a caller and suddenly gets a stack protector. > > __always_inline void scs_test3(void) > { > asm volatile("mov x3, x3\n\t":::"x30"); > } > > //no scs insns inserted > __noscs void scs_test4(void) > { > scs_test3(); > } > > ffff800010012900 <scs_test1>: > ffff800010012900: a9bf7bfd stp x29, x30, [sp, #-16]! > ffff800010012904: 910003fd mov x29, sp > ffff800010012908: aa0103e1 mov x1, x1 > ffff80001001290c: a8c17bfd ldp x29, x30, [sp], #16 > ffff800010012910: d65f03c0 ret > > ffff800010012914 <scs_test2>: > ffff800010012914: f800865e str x30, [x18], #8 > ffff800010012918: a9bf7bfd stp x29, x30, [sp, #-16]! > ffff80001001291c: 910003fd mov x29, sp > ffff800010012920: aa0103e1 mov x1, x1 > ffff800010012924: a8c17bfd ldp x29, x30, [sp], #16 > ffff800010012928: f85f8e5e ldr x30, [x18, #-8]! > ffff80001001292c: d65f03c0 ret > > ffff800010012930 <scs_test3>: > ffff800010012930: f800865e str x30, [x18], #8 > ffff800010012934: a9bf7bfd stp x29, x30, [sp, #-16]! > ffff800010012938: 910003fd mov x29, sp > ffff80001001293c: aa0303e3 mov x3, x3 > ffff800010012940: a8c17bfd ldp x29, x30, [sp], #16 > ffff800010012944: f85f8e5e ldr x30, [x18, #-8]! > ffff800010012948: d65f03c0 ret > ffff80001001294c: d503201f nop > > ffff800010012950 <scs_test4>: > ffff800010012950: a9bf7bfd stp x29, x30, [sp, #-16]! > ffff800010012954: 910003fd mov x29, sp > ffff800010012958: aa0303e3 mov x3, x3 > ffff80001001295c: a8c17bfd ldp x29, x30, [sp], #16 > ffff800010012960: d65f03c0 ret > > I noticed that __noscs isn't actually applied anywhere in the kernel, > > yet, at least in this series. Were there any places necessary that > > you've found thus far? > At present, I have not found a function that must use the __noscs > attribute in the kernel. I have only used this attribute in test cases. -- Thanks, ~Nick Desaulniers
WARNING: multiple messages have this Message-ID (diff)
From: Nick Desaulniers <ndesaulniers@google.com> To: Dan Li <ashimida@linux.alibaba.com> Cc: masahiroy@kernel.org, michal.lkml@markovi.net, catalin.marinas@arm.com, will@kernel.org, keescook@chromium.org, nathan@kernel.org, tglx@linutronix.de, akpm@linux-foundation.org, samitolvanen@google.com, frederic@kernel.org, rppt@kernel.org, mark.rutland@arm.com, yifeifz2@illinois.edu, rostedt@goodmis.org, viresh.kumar@linaro.org, andreyknvl@gmail.com, colin.king@canonical.com, ojeda@kernel.org, luc.vanoostenryck@gmail.com, elver@google.com, nivedita@alum.mit.edu, ardb@kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-hardening@vger.kernel.org, clang-built-linux@googlegroups.com Subject: Re: [PATCH] [PATCH V4]ARM64: SCS: Add gcc plugin to support Shadow Call Stack Date: Fri, 15 Oct 2021 12:13:33 -0700 [thread overview] Message-ID: <CAKwvOdnMvBP-1=YbXTpYOgWqCBy44tUvWdtMXp8p485bYnPYNQ@mail.gmail.com> (raw) In-Reply-To: <722d9662-e27c-2efb-e8cf-d505b6950475@linux.alibaba.com> On Fri, Oct 15, 2021 at 11:29 AM Dan Li <ashimida@linux.alibaba.com> wrote: > > > > On 10/15/21 2:44 AM, Nick Desaulniers wrote: > > On Wed, Oct 13, 2021 at 4:28 PM Dan Li <ashimida@linux.alibaba.com> wrote: > >> --- a/include/linux/compiler-gcc.h > >> +++ b/include/linux/compiler-gcc.h > >> @@ -50,6 +50,10 @@ > >> #define __latent_entropy __attribute__((latent_entropy)) > >> #endif > >> > >> +#if defined(SHADOW_CALL_STACK_PLUGIN) && !defined(__CHECKER__) > >> +#define __noscs __attribute__((no_shadow_call_stack)) > >> +#endif > > > > Cool this is a nice addition, and something I don't think that clang > > has. For any new feature, having a function attribute to disable it > > at the function granularity is nice, and plays better with LTO than -f > > group flags. Though that begs the question: what happens if a __noscs > > callee is inlined into a non-__noscs caller, or vice versa? > Thanks Nick, > > According to my understanding, all inline optimizations in gcc should > happen before inserting scs insns (scs and paciasp/autiasp use the > same insertion point). Therefore, the check for the __noscs attribute > will also occur after all inlining is completed. > > As in the following example: > - Since __noscs attribute is specified, scs_test1 does not insert scs insns > - Since normal functions scs_test2/3 uses x30, it needs to insert scs insns > - Since __noscs attribute is specified, scs_test4 after inlining does not > need to insert scs insns > > __always_inline __noscs void scs_test1(void) > { > asm volatile("mov x1, x1\n\t":::"x30"); > } > > //scs insns inserted after function inline > void scs_test2(void) > { > scs_test1(); > } That may be surprising to developers. Perhaps __always_inline on scs_test1 is distracting this test case, but I suspect it may not make a difference. This particular issue comes up time and again with stack protectors; ie. the callee is marked no stack protector, then gets inlined into a caller and suddenly gets a stack protector. > > __always_inline void scs_test3(void) > { > asm volatile("mov x3, x3\n\t":::"x30"); > } > > //no scs insns inserted > __noscs void scs_test4(void) > { > scs_test3(); > } > > ffff800010012900 <scs_test1>: > ffff800010012900: a9bf7bfd stp x29, x30, [sp, #-16]! > ffff800010012904: 910003fd mov x29, sp > ffff800010012908: aa0103e1 mov x1, x1 > ffff80001001290c: a8c17bfd ldp x29, x30, [sp], #16 > ffff800010012910: d65f03c0 ret > > ffff800010012914 <scs_test2>: > ffff800010012914: f800865e str x30, [x18], #8 > ffff800010012918: a9bf7bfd stp x29, x30, [sp, #-16]! > ffff80001001291c: 910003fd mov x29, sp > ffff800010012920: aa0103e1 mov x1, x1 > ffff800010012924: a8c17bfd ldp x29, x30, [sp], #16 > ffff800010012928: f85f8e5e ldr x30, [x18, #-8]! > ffff80001001292c: d65f03c0 ret > > ffff800010012930 <scs_test3>: > ffff800010012930: f800865e str x30, [x18], #8 > ffff800010012934: a9bf7bfd stp x29, x30, [sp, #-16]! > ffff800010012938: 910003fd mov x29, sp > ffff80001001293c: aa0303e3 mov x3, x3 > ffff800010012940: a8c17bfd ldp x29, x30, [sp], #16 > ffff800010012944: f85f8e5e ldr x30, [x18, #-8]! > ffff800010012948: d65f03c0 ret > ffff80001001294c: d503201f nop > > ffff800010012950 <scs_test4>: > ffff800010012950: a9bf7bfd stp x29, x30, [sp, #-16]! > ffff800010012954: 910003fd mov x29, sp > ffff800010012958: aa0303e3 mov x3, x3 > ffff80001001295c: a8c17bfd ldp x29, x30, [sp], #16 > ffff800010012960: d65f03c0 ret > > I noticed that __noscs isn't actually applied anywhere in the kernel, > > yet, at least in this series. Were there any places necessary that > > you've found thus far? > At present, I have not found a function that must use the __noscs > attribute in the kernel. I have only used this attribute in test cases. -- Thanks, ~Nick Desaulniers _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-10-15 19:13 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-10-13 23:27 [PATCH] [PATCH V4]ARM64: SCS: Add gcc plugin to support Shadow Call Stack Dan Li 2021-10-13 23:27 ` Dan Li 2021-10-14 18:44 ` Nick Desaulniers 2021-10-14 18:44 ` Nick Desaulniers 2021-10-15 18:28 ` Dan Li 2021-10-15 18:28 ` Dan Li 2021-10-15 19:10 ` Nick Desaulniers 2021-10-15 19:10 ` Nick Desaulniers 2021-10-15 19:13 ` Nick Desaulniers [this message] 2021-10-15 19:13 ` Nick Desaulniers 2021-10-15 21:52 ` Dan Li 2021-10-15 21:52 ` Dan Li
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='CAKwvOdnMvBP-1=YbXTpYOgWqCBy44tUvWdtMXp8p485bYnPYNQ@mail.gmail.com' \ --to=ndesaulniers@google.com \ --cc=akpm@linux-foundation.org \ --cc=andreyknvl@gmail.com \ --cc=ardb@kernel.org \ --cc=ashimida@linux.alibaba.com \ --cc=catalin.marinas@arm.com \ --cc=clang-built-linux@googlegroups.com \ --cc=colin.king@canonical.com \ --cc=elver@google.com \ --cc=frederic@kernel.org \ --cc=keescook@chromium.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-hardening@vger.kernel.org \ --cc=linux-kbuild@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luc.vanoostenryck@gmail.com \ --cc=mark.rutland@arm.com \ --cc=masahiroy@kernel.org \ --cc=michal.lkml@markovi.net \ --cc=nathan@kernel.org \ --cc=nivedita@alum.mit.edu \ --cc=ojeda@kernel.org \ --cc=rostedt@goodmis.org \ --cc=rppt@kernel.org \ --cc=samitolvanen@google.com \ --cc=tglx@linutronix.de \ --cc=viresh.kumar@linaro.org \ --cc=will@kernel.org \ --cc=yifeifz2@illinois.edu \ /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.