From: Nicolas Boichat <drinkcat@chromium.org> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alexandre Chartre <alexandre.chartre@oracle.com>, stable <stable@vger.kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Peter Zijlstra <peterz@infradead.org>, Arnd Bergmann <arnd@arndb.de>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Christopher Li <sparse@chrisli.org>, Daniel Axtens <dja@axtens.net>, Masahiro Yamada <yamada.masahiro@socionext.com>, Michael Ellerman <mpe@ellerman.id.au>, Michal Marek <michal.lkml@markovi.net>, "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>, Nicholas Piggin <npiggin@gmail.com>, Paul Mackerras <paulus@samba.org>, Sasha Levin <sashal@kernel.org>, linux-arch@vger.kernel.org, linux-kbuild@vger.kernel.org, lkml <linux-kernel@vger.kernel.org>, linux-sparse@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Guenter Roeck <groeck@chromium.org> Subject: Re: [for-stable-4.19 PATCH 1/2] vmlinux.lds.h: Create section for protection against instrumentation Date: Sat, 20 Mar 2021 06:48:41 +0800 [thread overview] Message-ID: <CANMq1KDsqsF2AOeY033rUj_Sit57a7O77kZ9Ob=56veGLK_H+Q@mail.gmail.com> (raw) In-Reply-To: <YFSRRux3FHJVgWXt@kroah.com> On Fri, Mar 19, 2021 at 7:55 PM Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > On Fri, Mar 19, 2021 at 12:20:22PM +0100, Alexandre Chartre wrote: > > > > On 3/19/21 11:39 AM, Greg Kroah-Hartman wrote: > > > On Fri, Mar 19, 2021 at 07:54:15AM +0800, Nicolas Boichat wrote: > > > > From: Thomas Gleixner <tglx@linutronix.de> > > > > > > > > commit 6553896666433e7efec589838b400a2a652b3ffa upstream. > > > > > > > > Some code pathes, especially the low level entry code, must be protected > > > > against instrumentation for various reasons: > > > > > > > > - Low level entry code can be a fragile beast, especially on x86. > > > > > > > > - With NO_HZ_FULL RCU state needs to be established before using it. > > > > > > > > Having a dedicated section for such code allows to validate with tooling > > > > that no unsafe functions are invoked. > > > > > > > > Add the .noinstr.text section and the noinstr attribute to mark > > > > functions. noinstr implies notrace. Kprobes will gain a section check > > > > later. > > > > > > > > Provide also a set of markers: instrumentation_begin()/end() > > > > > > > > These are used to mark code inside a noinstr function which calls > > > > into regular instrumentable text section as safe. > > > > > > > > The instrumentation markers are only active when CONFIG_DEBUG_ENTRY is > > > > enabled as the end marker emits a NOP to prevent the compiler from merging > > > > the annotation points. This means the objtool verification requires a > > > > kernel compiled with this option. > > > > > > > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > > > > Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com> > > > > Acked-by: Peter Zijlstra <peterz@infradead.org> > > > > Link: https://lkml.kernel.org/r/20200505134100.075416272@linutronix.de > > > > > > > > [Nicolas: context conflicts in: > > > > arch/powerpc/kernel/vmlinux.lds.S > > > > include/asm-generic/vmlinux.lds.h > > > > include/linux/compiler.h > > > > include/linux/compiler_types.h] > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > > > > Did you build this on x86? > > > > > > I get the following build error: > > > > > > ld:./arch/x86/kernel/vmlinux.lds:20: syntax error > > > > > > And that line looks like: > > > > > > . = ALIGN(8); *(.text.hot .text.hot.*) *(.text .text.fixup) *(.text.unlikely .text.unlikely.*) *(.text.unknown .text.unknown.*) . = ALIGN(8); __noinstr_text_start = .; *(.__attribute__((noinline)) __attribute__((no_instrument_function)) __attribute((__section__(".noinstr.text"))).text) __noinstr_text_end = .; *(.text..refcount) *(.ref.text) *(.meminit.text*) *(.memexit.text*) > > > > > > > In the NOINSTR_TEXT macro, noinstr is expanded with the value of the noinstr > > macro from linux/compiler_types.h while it shouldn't. > > > > The problem is possibly that the noinstr macro is defined for assembly. Make > > sure that the macro is not defined for assembly e.g.: > > > > #ifndef __ASSEMBLY__ > > > > /* Section for code which can't be instrumented at all */ > > #define noinstr \ > > noinline notrace __attribute((__section__(".noinstr.text"))) > > > > #endif > > This implies that the backport is incorrect, so I'll wait for an updated > version... Yep, sorry about that. I did test on ARM64 only and these patches happily went through our Chrome OS CQ (we don't have gcc coverage though). Guenter has a fixup here with explanation: https://crrev.com/c/2776332, I'll look carefully and resubmit. Thanks, > thanks, > > greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Boichat <drinkcat@chromium.org> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Sasha Levin <sashal@kernel.org>, linux-arch@vger.kernel.org, Michal Marek <michal.lkml@markovi.net>, Alexandre Chartre <alexandre.chartre@oracle.com>, Arnd Bergmann <arnd@arndb.de>, linux-kbuild@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>, Christopher Li <sparse@chrisli.org>, lkml <linux-kernel@vger.kernel.org>, stable <stable@vger.kernel.org>, Masahiro Yamada <yamada.masahiro@socionext.com>, linux-sparse@vger.kernel.org, Paul Mackerras <paulus@samba.org>, Nicholas Piggin <npiggin@gmail.com>, Guenter Roeck <groeck@chromium.org>, Thomas Gleixner <tglx@linutronix.de>, linuxppc-dev@lists.ozlabs.org, "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>, Daniel Axtens <dja@axtens.net> Subject: Re: [for-stable-4.19 PATCH 1/2] vmlinux.lds.h: Create section for protection against instrumentation Date: Sat, 20 Mar 2021 06:48:41 +0800 [thread overview] Message-ID: <CANMq1KDsqsF2AOeY033rUj_Sit57a7O77kZ9Ob=56veGLK_H+Q@mail.gmail.com> (raw) In-Reply-To: <YFSRRux3FHJVgWXt@kroah.com> On Fri, Mar 19, 2021 at 7:55 PM Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > On Fri, Mar 19, 2021 at 12:20:22PM +0100, Alexandre Chartre wrote: > > > > On 3/19/21 11:39 AM, Greg Kroah-Hartman wrote: > > > On Fri, Mar 19, 2021 at 07:54:15AM +0800, Nicolas Boichat wrote: > > > > From: Thomas Gleixner <tglx@linutronix.de> > > > > > > > > commit 6553896666433e7efec589838b400a2a652b3ffa upstream. > > > > > > > > Some code pathes, especially the low level entry code, must be protected > > > > against instrumentation for various reasons: > > > > > > > > - Low level entry code can be a fragile beast, especially on x86. > > > > > > > > - With NO_HZ_FULL RCU state needs to be established before using it. > > > > > > > > Having a dedicated section for such code allows to validate with tooling > > > > that no unsafe functions are invoked. > > > > > > > > Add the .noinstr.text section and the noinstr attribute to mark > > > > functions. noinstr implies notrace. Kprobes will gain a section check > > > > later. > > > > > > > > Provide also a set of markers: instrumentation_begin()/end() > > > > > > > > These are used to mark code inside a noinstr function which calls > > > > into regular instrumentable text section as safe. > > > > > > > > The instrumentation markers are only active when CONFIG_DEBUG_ENTRY is > > > > enabled as the end marker emits a NOP to prevent the compiler from merging > > > > the annotation points. This means the objtool verification requires a > > > > kernel compiled with this option. > > > > > > > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > > > > Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com> > > > > Acked-by: Peter Zijlstra <peterz@infradead.org> > > > > Link: https://lkml.kernel.org/r/20200505134100.075416272@linutronix.de > > > > > > > > [Nicolas: context conflicts in: > > > > arch/powerpc/kernel/vmlinux.lds.S > > > > include/asm-generic/vmlinux.lds.h > > > > include/linux/compiler.h > > > > include/linux/compiler_types.h] > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > > > > Did you build this on x86? > > > > > > I get the following build error: > > > > > > ld:./arch/x86/kernel/vmlinux.lds:20: syntax error > > > > > > And that line looks like: > > > > > > . = ALIGN(8); *(.text.hot .text.hot.*) *(.text .text.fixup) *(.text.unlikely .text.unlikely.*) *(.text.unknown .text.unknown.*) . = ALIGN(8); __noinstr_text_start = .; *(.__attribute__((noinline)) __attribute__((no_instrument_function)) __attribute((__section__(".noinstr.text"))).text) __noinstr_text_end = .; *(.text..refcount) *(.ref.text) *(.meminit.text*) *(.memexit.text*) > > > > > > > In the NOINSTR_TEXT macro, noinstr is expanded with the value of the noinstr > > macro from linux/compiler_types.h while it shouldn't. > > > > The problem is possibly that the noinstr macro is defined for assembly. Make > > sure that the macro is not defined for assembly e.g.: > > > > #ifndef __ASSEMBLY__ > > > > /* Section for code which can't be instrumented at all */ > > #define noinstr \ > > noinline notrace __attribute((__section__(".noinstr.text"))) > > > > #endif > > This implies that the backport is incorrect, so I'll wait for an updated > version... Yep, sorry about that. I did test on ARM64 only and these patches happily went through our Chrome OS CQ (we don't have gcc coverage though). Guenter has a fixup here with explanation: https://crrev.com/c/2776332, I'll look carefully and resubmit. Thanks, > thanks, > > greg k-h
next prev parent reply other threads:[~2021-03-19 22:49 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-18 23:54 [for-stable-4.19 PATCH 0/2] Backport patches to fix KASAN+LKDTM with recent clang on ARM64 Nicolas Boichat 2021-03-18 23:54 ` Nicolas Boichat 2021-03-18 23:54 ` [for-stable-4.19 PATCH 1/2] vmlinux.lds.h: Create section for protection against instrumentation Nicolas Boichat 2021-03-18 23:54 ` Nicolas Boichat 2021-03-19 10:39 ` Greg Kroah-Hartman 2021-03-19 10:39 ` Greg Kroah-Hartman 2021-03-19 11:20 ` Alexandre Chartre 2021-03-19 11:20 ` Alexandre Chartre 2021-03-19 11:55 ` Greg Kroah-Hartman 2021-03-19 11:55 ` Greg Kroah-Hartman 2021-03-19 22:48 ` Nicolas Boichat [this message] 2021-03-19 22:48 ` Nicolas Boichat 2021-03-18 23:54 ` [for-stable-4.19 PATCH 2/2] lkdtm: don't move ctors to .rodata Nicolas Boichat 2021-03-19 10:30 ` [for-stable-4.19 PATCH 0/2] Backport patches to fix KASAN+LKDTM with recent clang on ARM64 Greg Kroah-Hartman 2021-03-19 10:30 ` Greg Kroah-Hartman
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='CANMq1KDsqsF2AOeY033rUj_Sit57a7O77kZ9Ob=56veGLK_H+Q@mail.gmail.com' \ --to=drinkcat@chromium.org \ --cc=alexandre.chartre@oracle.com \ --cc=arnd@arndb.de \ --cc=benh@kernel.crashing.org \ --cc=dja@axtens.net \ --cc=gregkh@linuxfoundation.org \ --cc=groeck@chromium.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kbuild@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-sparse@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=michal.lkml@markovi.net \ --cc=mpe@ellerman.id.au \ --cc=naveen.n.rao@linux.vnet.ibm.com \ --cc=npiggin@gmail.com \ --cc=paulus@samba.org \ --cc=peterz@infradead.org \ --cc=sashal@kernel.org \ --cc=sparse@chrisli.org \ --cc=stable@vger.kernel.org \ --cc=tglx@linutronix.de \ --cc=yamada.masahiro@socionext.com \ /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.