Linux-Toolchains Archive at lore.kernel.org
 help / color / Atom feed
* Re: Linux Plumbers Conf 2021
       [not found]   ` <20210518124311.r4fwv6lfz3erkqnb@treble>
@ 2021-05-18 12:48     ` Josh Poimboeuf
  2021-05-18 13:21       ` Peter Zijlstra
  0 siblings, 1 reply; 16+ messages in thread
From: Josh Poimboeuf @ 2021-05-18 12:48 UTC (permalink / raw)
  To: Will Deacon
  Cc: Nick Desaulniers, Jose E. Marchesi, Paul E. McKenney, peterz,
	ardb, catalin.marinas, mark.rutland, linux-toolchains

Fixing linux-toolchains list address.

On Tue, May 18, 2021 at 07:43:13AM -0500, Josh Poimboeuf wrote:
> On Tue, May 18, 2021 at 01:14:48PM +0100, Will Deacon wrote:
> > If it's not too late, I'd definitely be interested in a discussion around
> > objtool support for arm64. Specifically, I would very much like us _not_
> > to have a hard dependency on objtool and instead treat it as a binary
> > linter of sorts. However, this likely requires help from the toolchain
> > where some of the jobs which are performed by objtool on x86 today now
> > need to be done by the compiler/linker for arm64.
> > 
> > I don't have a good handle on exactly what is needed and whether there's
> > any appetite from the toolchain developers to implement this, so it would
> > be very helpful to kick that discussion off.
> 
> Objtool stack validation already is pretty much a "binary linter".  If
> all the warnings are fixed then we can trust the unwind metadata (e.g.
> frame pointers) for reliable unwinding / live patching.
> 
> All warnings are expected to be fixed by humans, so objtool doesn't have
> to edit the binary (assuming no ORC, which is optional).  Objtool is
> only considered a hard dependency for live patching because unfixed
> warnings could mean a livepatch fail.
> 
> So I wonder what specifically you have in mind?
> 
> -- 
> Josh

-- 
Josh


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Linux Plumbers Conf 2021
  2021-05-18 12:48     ` Linux Plumbers Conf 2021 Josh Poimboeuf
@ 2021-05-18 13:21       ` Peter Zijlstra
  2021-05-18 16:57         ` Nick Desaulniers
  0 siblings, 1 reply; 16+ messages in thread
From: Peter Zijlstra @ 2021-05-18 13:21 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Will Deacon, Nick Desaulniers, Jose E. Marchesi,
	Paul E. McKenney, ardb, catalin.marinas, mark.rutland,
	linux-toolchains

On Tue, May 18, 2021 at 07:48:19AM -0500, Josh Poimboeuf wrote:
> Fixing linux-toolchains list address.
> 
> On Tue, May 18, 2021 at 07:43:13AM -0500, Josh Poimboeuf wrote:
> > On Tue, May 18, 2021 at 01:14:48PM +0100, Will Deacon wrote:
> > > If it's not too late, I'd definitely be interested in a discussion around
> > > objtool support for arm64. Specifically, I would very much like us _not_
> > > to have a hard dependency on objtool and instead treat it as a binary
> > > linter of sorts. However, this likely requires help from the toolchain
> > > where some of the jobs which are performed by objtool on x86 today now
> > > need to be done by the compiler/linker for arm64.
> > > 
> > > I don't have a good handle on exactly what is needed and whether there's
> > > any appetite from the toolchain developers to implement this, so it would
> > > be very helpful to kick that discussion off.
> > 
> > Objtool stack validation already is pretty much a "binary linter".  If
> > all the warnings are fixed then we can trust the unwind metadata (e.g.
> > frame pointers) for reliable unwinding / live patching.
> > 
> > All warnings are expected to be fixed by humans, so objtool doesn't have
> > to edit the binary (assuming no ORC, which is optional).  Objtool is
> > only considered a hard dependency for live patching because unfixed
> > warnings could mean a livepatch fail.
> > 
> > So I wonder what specifically you have in mind?

Things objtool does (in no apparent order):

 - validate stack frames

 - generate ORC unwind data (optional)

 - validates unreachable instructions; specifically the lack thereof
   (optional)

 - validates retpoline; or specifically the lack of indirect jump/call
   sites (with annotations for those few that are okay). (optional)

 - validates uaccess rules; specifically no call/ret in between
   __user_access_begin() and __user_access_end(). (optional)

 - validates noinstr annotation; *HOWEVER* we rely on objtool to NOP
   all __sanitizer_cov_* calls in .noinstr/.entry text sections because
   __no_sanitize_cov is 'broken' in all known compilers.

 - generates __mcount_loc section and NOPs the __fentry call sites
   (optional)

 - generates .static_call_sites section for STATIC_CALL_INLINE support

 - rewrites compiler generates call/jump to the retpoline thunk to an
   alternative such that we can patch out the thunk with an indirect
   call/jmp when retpolines are disabled. (arch dependent)

 - rewrites specific jmp.d8 sites (as found through the __jump_table
   section) to nop2, because GAS is unable to determine if a jmp becomes
   a jmp.d8 or jmp.d32 and emit the right sized nop. (optional)


So all except the __sanitize_cov__ crud would be fine, but that thing in
specific really wants fixing in the toolchains. Aside of that, all the
things where objtool generates/modifies sections/code are optional and
or architecture dependent.

Aside of that, objtool depends on being able to reconstruct the code
flow as generated by the compiler and a few code-gen options are known
to generate things objtool simply cannot follow, arm64 in specific had
some trouble with jump-tables.



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Linux Plumbers Conf 2021
  2021-05-18 13:21       ` Peter Zijlstra
@ 2021-05-18 16:57         ` Nick Desaulniers
  2021-05-18 20:03           ` Peter Zijlstra
  0 siblings, 1 reply; 16+ messages in thread
From: Nick Desaulniers @ 2021-05-18 16:57 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Josh Poimboeuf, Will Deacon, Jose E. Marchesi, Paul E. McKenney,
	Ard Biesheuvel, Catalin Marinas, Mark Rutland, linux-toolchains

On Tue, May 18, 2021 at 6:23 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Tue, May 18, 2021 at 07:48:19AM -0500, Josh Poimboeuf wrote:
> > Fixing linux-toolchains list address.
> >
> > On Tue, May 18, 2021 at 07:43:13AM -0500, Josh Poimboeuf wrote:
> > > On Tue, May 18, 2021 at 01:14:48PM +0100, Will Deacon wrote:
> > > > If it's not too late, I'd definitely be interested in a discussion around
> > > > objtool support for arm64. Specifically, I would very much like us _not_
> > > > to have a hard dependency on objtool and instead treat it as a binary
> > > > linter of sorts. However, this likely requires help from the toolchain
> > > > where some of the jobs which are performed by objtool on x86 today now
> > > > need to be done by the compiler/linker for arm64.
> > > >
> > > > I don't have a good handle on exactly what is needed and whether there's
> > > > any appetite from the toolchain developers to implement this, so it would
> > > > be very helpful to kick that discussion off.
> > >
> > > Objtool stack validation already is pretty much a "binary linter".  If
> > > all the warnings are fixed then we can trust the unwind metadata (e.g.
> > > frame pointers) for reliable unwinding / live patching.
> > >
> > > All warnings are expected to be fixed by humans, so objtool doesn't have
> > > to edit the binary (assuming no ORC, which is optional).  Objtool is
> > > only considered a hard dependency for live patching because unfixed
> > > warnings could mean a livepatch fail.
> > >
> > > So I wonder what specifically you have in mind?
>
> Things objtool does (in no apparent order):
>
>  - validate stack frames
>
>  - generate ORC unwind data (optional)
>
>  - validates unreachable instructions; specifically the lack thereof
>    (optional)
>
>  - validates retpoline; or specifically the lack of indirect jump/call
>    sites (with annotations for those few that are okay). (optional)
>
>  - validates uaccess rules; specifically no call/ret in between
>    __user_access_begin() and __user_access_end(). (optional)
>
>  - validates noinstr annotation; *HOWEVER* we rely on objtool to NOP
>    all __sanitizer_cov_* calls in .noinstr/.entry text sections because
>    __no_sanitize_cov is 'broken' in all known compilers.

^ Do you have more information on this?

>
>  - generates __mcount_loc section and NOPs the __fentry call sites
>    (optional)
>
>  - generates .static_call_sites section for STATIC_CALL_INLINE support
>
>  - rewrites compiler generates call/jump to the retpoline thunk to an
>    alternative such that we can patch out the thunk with an indirect
>    call/jmp when retpolines are disabled. (arch dependent)
>
>  - rewrites specific jmp.d8 sites (as found through the __jump_table
>    section) to nop2, because GAS is unable to determine if a jmp becomes
>    a jmp.d8 or jmp.d32 and emit the right sized nop. (optional)
>
>
> So all except the __sanitize_cov__ crud would be fine, but that thing in
> specific really wants fixing in the toolchains. Aside of that, all the
> things where objtool generates/modifies sections/code are optional and
> or architecture dependent.
>
> Aside of that, objtool depends on being able to reconstruct the code
> flow as generated by the compiler and a few code-gen options are known
> to generate things objtool simply cannot follow, arm64 in specific had
> some trouble with jump-tables.
>
>


-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Linux Plumbers Conf 2021
  2021-05-18 16:57         ` Nick Desaulniers
@ 2021-05-18 20:03           ` Peter Zijlstra
  2021-05-18 20:15             ` Nick Desaulniers
  2021-05-19  9:32             ` Mark Rutland
  0 siblings, 2 replies; 16+ messages in thread
From: Peter Zijlstra @ 2021-05-18 20:03 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: Josh Poimboeuf, Will Deacon, Jose E. Marchesi, Paul E. McKenney,
	Ard Biesheuvel, Catalin Marinas, Mark Rutland, linux-toolchains

On Tue, May 18, 2021 at 09:57:26AM -0700, Nick Desaulniers wrote:
> On Tue, May 18, 2021 at 6:23 AM Peter Zijlstra <peterz@infradead.org> wrote:

> >  - validates noinstr annotation; *HOWEVER* we rely on objtool to NOP
> >    all __sanitizer_cov_* calls in .noinstr/.entry text sections because
> >    __no_sanitize_cov is 'broken' in all known compilers.
> 
> ^ Do you have more information on this?

Random link in the middle of a relevant thread:

  https://lkml.kernel.org/r/CANpmjNPNa2f=kAF6c199oYVJ0iSyirQRGxeOBLxa9PmakSXRbA@mail.gmail.com

Notable quote:

"It's everywhere. We cannot mark noinstr functions to not be
instrumented by KCOV/-fsanitize-coverage, because no compiler provides
an attribute to do so. GCC doesn't have
__attribute__((no_sanitize_coverage)) and Clang doesn't have
__attribute__((no_sanitize("coverage")), and therefore we can't have
__no_sanitize_coverage."



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Linux Plumbers Conf 2021
  2021-05-18 20:03           ` Peter Zijlstra
@ 2021-05-18 20:15             ` Nick Desaulniers
  2021-05-19  9:32             ` Mark Rutland
  1 sibling, 0 replies; 16+ messages in thread
From: Nick Desaulniers @ 2021-05-18 20:15 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Josh Poimboeuf, Will Deacon, Jose E. Marchesi, Paul E. McKenney,
	Ard Biesheuvel, Catalin Marinas, Mark Rutland, linux-toolchains

On Tue, May 18, 2021 at 1:06 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Tue, May 18, 2021 at 09:57:26AM -0700, Nick Desaulniers wrote:
> > On Tue, May 18, 2021 at 6:23 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> > >  - validates noinstr annotation; *HOWEVER* we rely on objtool to NOP
> > >    all __sanitizer_cov_* calls in .noinstr/.entry text sections because
> > >    __no_sanitize_cov is 'broken' in all known compilers.
> >
> > ^ Do you have more information on this?
>
> Random link in the middle of a relevant thread:
>
>   https://lkml.kernel.org/r/CANpmjNPNa2f=kAF6c199oYVJ0iSyirQRGxeOBLxa9PmakSXRbA@mail.gmail.com
>
> Notable quote:
>
> "It's everywhere. We cannot mark noinstr functions to not be
> instrumented by KCOV/-fsanitize-coverage, because no compiler provides
> an attribute to do so. GCC doesn't have
> __attribute__((no_sanitize_coverage)) and Clang doesn't have
> __attribute__((no_sanitize("coverage")), and therefore we can't have
> __no_sanitize_coverage."

Cool, thanks for the context.  I was able to find this bug filed by
Marco: https://bugs.llvm.org/show_bug.cgi?id=49035. I've cc'ed myself.
We'll follow up on that.
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Linux Plumbers Conf 2021
  2021-05-18 20:03           ` Peter Zijlstra
  2021-05-18 20:15             ` Nick Desaulniers
@ 2021-05-19  9:32             ` Mark Rutland
  2021-05-19 10:19               ` Marco Elver
  1 sibling, 1 reply; 16+ messages in thread
From: Mark Rutland @ 2021-05-19  9:32 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Nick Desaulniers, Josh Poimboeuf, Will Deacon, Jose E. Marchesi,
	Paul E. McKenney, Ard Biesheuvel, Catalin Marinas,
	linux-toolchains

On Tue, May 18, 2021 at 10:03:06PM +0200, Peter Zijlstra wrote:
> On Tue, May 18, 2021 at 09:57:26AM -0700, Nick Desaulniers wrote:
> > On Tue, May 18, 2021 at 6:23 AM Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > >  - validates noinstr annotation; *HOWEVER* we rely on objtool to NOP
> > >    all __sanitizer_cov_* calls in .noinstr/.entry text sections because
> > >    __no_sanitize_cov is 'broken' in all known compilers.
> > 
> > ^ Do you have more information on this?
> 
> Random link in the middle of a relevant thread:
> 
>   https://lkml.kernel.org/r/CANpmjNPNa2f=kAF6c199oYVJ0iSyirQRGxeOBLxa9PmakSXRbA@mail.gmail.com
> 
> Notable quote:
> 
> "It's everywhere. We cannot mark noinstr functions to not be
> instrumented by KCOV/-fsanitize-coverage, because no compiler provides
> an attribute to do so. GCC doesn't have
> __attribute__((no_sanitize_coverage)) and Clang doesn't have
> __attribute__((no_sanitize("coverage")), and therefore we can't have
> __no_sanitize_coverage."

Yuck; I wasn't aware of that.

This means that arm64's entry code is unsound (along with some other
parts) if kcov is enabled.

That *really* needs an attribute, and going forward we shouldn't accept
new compiler instrumentation that we can't opt-out of like this.

Thanks,
Mark.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Linux Plumbers Conf 2021
  2021-05-19  9:32             ` Mark Rutland
@ 2021-05-19 10:19               ` Marco Elver
  2021-05-19 11:56                 ` Mark Rutland
  0 siblings, 1 reply; 16+ messages in thread
From: Marco Elver @ 2021-05-19 10:19 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Peter Zijlstra, Nick Desaulniers, Josh Poimboeuf, Will Deacon,
	Jose E. Marchesi, Paul E. McKenney, Ard Biesheuvel,
	Catalin Marinas, linux-toolchains

On Wed, 19 May 2021 at 11:32, Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Tue, May 18, 2021 at 10:03:06PM +0200, Peter Zijlstra wrote:
> > On Tue, May 18, 2021 at 09:57:26AM -0700, Nick Desaulniers wrote:
> > > On Tue, May 18, 2021 at 6:23 AM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > > >  - validates noinstr annotation; *HOWEVER* we rely on objtool to NOP
> > > >    all __sanitizer_cov_* calls in .noinstr/.entry text sections because
> > > >    __no_sanitize_cov is 'broken' in all known compilers.
> > >
> > > ^ Do you have more information on this?
> >
> > Random link in the middle of a relevant thread:
> >
> >   https://lkml.kernel.org/r/CANpmjNPNa2f=kAF6c199oYVJ0iSyirQRGxeOBLxa9PmakSXRbA@mail.gmail.com
> >
> > Notable quote:
> >
> > "It's everywhere. We cannot mark noinstr functions to not be
> > instrumented by KCOV/-fsanitize-coverage, because no compiler provides
> > an attribute to do so. GCC doesn't have
> > __attribute__((no_sanitize_coverage)) and Clang doesn't have
> > __attribute__((no_sanitize("coverage")), and therefore we can't have
> > __no_sanitize_coverage."

Hmm, we really need to add those. I looked at it briefly for Clang,
and I think it turned out more complicated than I thought and then
after seeing objtool "solved it", more pressing things came up. :-/

> Yuck; I wasn't aware of that.
>
> This means that arm64's entry code is unsound (along with some other
> parts) if kcov is enabled.

We still have "KCOV_INSTRUMENT_file.o := n" (or "KCOV_INSTRUMENT := n"
for everything in a Makefile) for now. Not great, but for entry code
it might be good enough.

> That *really* needs an attribute, and going forward we shouldn't accept
> new compiler instrumentation that we can't opt-out of like this.

Strangely enough, in Clang, there's -fsanitize-coverage-blocklist, but
that's pretty useless for the kernel. Maintaining a list of functions
doesn't scale, and we just need an attribute. I'll ping a few of the
people who know Clang's fsanitize-coverage a bit better.

Thanks,
-- Marco

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Linux Plumbers Conf 2021
  2021-05-19 10:19               ` Marco Elver
@ 2021-05-19 11:56                 ` Mark Rutland
  2021-05-19 14:04                   ` Marco Elver
  0 siblings, 1 reply; 16+ messages in thread
From: Mark Rutland @ 2021-05-19 11:56 UTC (permalink / raw)
  To: Marco Elver
  Cc: Peter Zijlstra, Nick Desaulniers, Josh Poimboeuf, Will Deacon,
	Jose E. Marchesi, Paul E. McKenney, Ard Biesheuvel,
	Catalin Marinas, linux-toolchains

On Wed, May 19, 2021 at 12:19:38PM +0200, Marco Elver wrote:
> On Wed, 19 May 2021 at 11:32, Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > On Tue, May 18, 2021 at 10:03:06PM +0200, Peter Zijlstra wrote:
> > > On Tue, May 18, 2021 at 09:57:26AM -0700, Nick Desaulniers wrote:
> > > > On Tue, May 18, 2021 at 6:23 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > > >  - validates noinstr annotation; *HOWEVER* we rely on objtool to NOP
> > > > >    all __sanitizer_cov_* calls in .noinstr/.entry text sections because
> > > > >    __no_sanitize_cov is 'broken' in all known compilers.
> > > >
> > > > ^ Do you have more information on this?
> > >
> > > Random link in the middle of a relevant thread:
> > >
> > >   https://lkml.kernel.org/r/CANpmjNPNa2f=kAF6c199oYVJ0iSyirQRGxeOBLxa9PmakSXRbA@mail.gmail.com
> > >
> > > Notable quote:
> > >
> > > "It's everywhere. We cannot mark noinstr functions to not be
> > > instrumented by KCOV/-fsanitize-coverage, because no compiler provides
> > > an attribute to do so. GCC doesn't have
> > > __attribute__((no_sanitize_coverage)) and Clang doesn't have
> > > __attribute__((no_sanitize("coverage")), and therefore we can't have
> > > __no_sanitize_coverage."
> 
> Hmm, we really need to add those. I looked at it briefly for Clang,
> and I think it turned out more complicated than I thought and then
> after seeing objtool "solved it", more pressing things came up. :-/
> 
> > Yuck; I wasn't aware of that.
> >
> > This means that arm64's entry code is unsound (along with some other
> > parts) if kcov is enabled.
> 
> We still have "KCOV_INSTRUMENT_file.o := n" (or "KCOV_INSTRUMENT := n"
> for everything in a Makefile) for now. Not great, but for entry code
> it might be good enough.

FWIW, I've prepared some patches to do just that; it requires moving
some functions around so that we don't unnecessarily prevent
instrumentation, but otherwise that does seem to be good enough for what
we have today.

I'll send that out shortly as part of some entry code rework.

> > That *really* needs an attribute, and going forward we shouldn't accept
> > new compiler instrumentation that we can't opt-out of like this.
> 
> Strangely enough, in Clang, there's -fsanitize-coverage-blocklist, but
> that's pretty useless for the kernel. Maintaining a list of functions
> doesn't scale, and we just need an attribute. I'll ping a few of the
> people who know Clang's fsanitize-coverage a bit better.

Great, thanks!

I think that kernel-side we should have a policy going forward that for
new instrumentation it must be possible to opt-out like this (and when
support is added, `noinstr` gets upsated to opt-out). Correspondingly on
the compiler-side, it'd be good if that was seen as a general
requirement for new instrumentation.

Thanks,
Mark.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Linux Plumbers Conf 2021
  2021-05-19 11:56                 ` Mark Rutland
@ 2021-05-19 14:04                   ` Marco Elver
  2021-05-19 15:02                     ` Martin Liška
  0 siblings, 1 reply; 16+ messages in thread
From: Marco Elver @ 2021-05-19 14:04 UTC (permalink / raw)
  To: Mark Rutland, Martin Liška
  Cc: Peter Zijlstra, Nick Desaulniers, Josh Poimboeuf, Will Deacon,
	Jose E. Marchesi, Paul E. McKenney, Ard Biesheuvel,
	Catalin Marinas, linux-toolchains

+Cc Martin, who helped us last time with no_sanitize issues in GCC.

Martin, as far as we're aware there's no
__attribute__((no_sanitize_coverage)) for GCC -- is it possible to
implement this? Some context below. Thank you.

On Wed, 19 May 2021 at 13:57, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, May 19, 2021 at 12:19:38PM +0200, Marco Elver wrote:
> > On Wed, 19 May 2021 at 11:32, Mark Rutland <mark.rutland@arm.com> wrote:
> > > On Tue, May 18, 2021 at 10:03:06PM +0200, Peter Zijlstra wrote:
> > > > On Tue, May 18, 2021 at 09:57:26AM -0700, Nick Desaulniers wrote:
> > > > > On Tue, May 18, 2021 at 6:23 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > > >
> > > > > >  - validates noinstr annotation; *HOWEVER* we rely on objtool to NOP
> > > > > >    all __sanitizer_cov_* calls in .noinstr/.entry text sections because
> > > > > >    __no_sanitize_cov is 'broken' in all known compilers.
> > > > >
> > > > > ^ Do you have more information on this?
> > > >
> > > > Random link in the middle of a relevant thread:
> > > >
> > > >   https://lkml.kernel.org/r/CANpmjNPNa2f=kAF6c199oYVJ0iSyirQRGxeOBLxa9PmakSXRbA@mail.gmail.com
> > > >
> > > > Notable quote:
> > > >
> > > > "It's everywhere. We cannot mark noinstr functions to not be
> > > > instrumented by KCOV/-fsanitize-coverage, because no compiler provides
> > > > an attribute to do so. GCC doesn't have
> > > > __attribute__((no_sanitize_coverage)) and Clang doesn't have
> > > > __attribute__((no_sanitize("coverage")), and therefore we can't have
> > > > __no_sanitize_coverage."
[...]
> > > That *really* needs an attribute, and going forward we shouldn't accept
> > > new compiler instrumentation that we can't opt-out of like this.
> >
> > Strangely enough, in Clang, there's -fsanitize-coverage-blocklist, but
> > that's pretty useless for the kernel. Maintaining a list of functions
> > doesn't scale, and we just need an attribute. I'll ping a few of the
> > people who know Clang's fsanitize-coverage a bit better.
>
> Great, thanks!

I did the simplest possible thing, so let's see if we can land this:
https://reviews.llvm.org/D102772

> I think that kernel-side we should have a policy going forward that for
> new instrumentation it must be possible to opt-out like this (and when
> support is added, `noinstr` gets upsated to opt-out). Correspondingly on
> the compiler-side, it'd be good if that was seen as a general
> requirement for new instrumentation.

No argument with that!

Thanks,
-- Marco

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Linux Plumbers Conf 2021
  2021-05-19 14:04                   ` Marco Elver
@ 2021-05-19 15:02                     ` Martin Liška
  2021-05-19 15:05                       ` Marco Elver
  0 siblings, 1 reply; 16+ messages in thread
From: Martin Liška @ 2021-05-19 15:02 UTC (permalink / raw)
  To: Marco Elver, Mark Rutland
  Cc: Peter Zijlstra, Nick Desaulniers, Josh Poimboeuf, Will Deacon,
	Jose E. Marchesi, Paul E. McKenney, Ard Biesheuvel,
	Catalin Marinas, linux-toolchains

On 5/19/21 4:04 PM, Marco Elver wrote:
> +Cc Martin, who helped us last time with no_sanitize issues in GCC.
> 
> Martin, as far as we're aware there's no
> __attribute__((no_sanitize_coverage)) for GCC -- is it possible to
> implement this? Some context below. Thank you.

Yes, I've just implemented the attribute and I'm going to send it to
the gcc-patches mailing list tomorrow.

Cheers,
Martin

> 
> On Wed, 19 May 2021 at 13:57, Mark Rutland <mark.rutland@arm.com> wrote:
>> On Wed, May 19, 2021 at 12:19:38PM +0200, Marco Elver wrote:
>>> On Wed, 19 May 2021 at 11:32, Mark Rutland <mark.rutland@arm.com> wrote:
>>>> On Tue, May 18, 2021 at 10:03:06PM +0200, Peter Zijlstra wrote:
>>>>> On Tue, May 18, 2021 at 09:57:26AM -0700, Nick Desaulniers wrote:
>>>>>> On Tue, May 18, 2021 at 6:23 AM Peter Zijlstra <peterz@infradead.org> wrote:
>>>>>
>>>>>>>   - validates noinstr annotation; *HOWEVER* we rely on objtool to NOP
>>>>>>>     all __sanitizer_cov_* calls in .noinstr/.entry text sections because
>>>>>>>     __no_sanitize_cov is 'broken' in all known compilers.
>>>>>>
>>>>>> ^ Do you have more information on this?
>>>>>
>>>>> Random link in the middle of a relevant thread:
>>>>>
>>>>>    https://lkml.kernel.org/r/CANpmjNPNa2f=kAF6c199oYVJ0iSyirQRGxeOBLxa9PmakSXRbA@mail.gmail.com
>>>>>
>>>>> Notable quote:
>>>>>
>>>>> "It's everywhere. We cannot mark noinstr functions to not be
>>>>> instrumented by KCOV/-fsanitize-coverage, because no compiler provides
>>>>> an attribute to do so. GCC doesn't have
>>>>> __attribute__((no_sanitize_coverage)) and Clang doesn't have
>>>>> __attribute__((no_sanitize("coverage")), and therefore we can't have
>>>>> __no_sanitize_coverage."
> [...]
>>>> That *really* needs an attribute, and going forward we shouldn't accept
>>>> new compiler instrumentation that we can't opt-out of like this.
>>>
>>> Strangely enough, in Clang, there's -fsanitize-coverage-blocklist, but
>>> that's pretty useless for the kernel. Maintaining a list of functions
>>> doesn't scale, and we just need an attribute. I'll ping a few of the
>>> people who know Clang's fsanitize-coverage a bit better.
>>
>> Great, thanks!
> 
> I did the simplest possible thing, so let's see if we can land this:
> https://reviews.llvm.org/D102772
> 
>> I think that kernel-side we should have a policy going forward that for
>> new instrumentation it must be possible to opt-out like this (and when
>> support is added, `noinstr` gets upsated to opt-out). Correspondingly on
>> the compiler-side, it'd be good if that was seen as a general
>> requirement for new instrumentation.
> 
> No argument with that!
> 
> Thanks,
> -- Marco
> 


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Linux Plumbers Conf 2021
  2021-05-19 15:02                     ` Martin Liška
@ 2021-05-19 15:05                       ` Marco Elver
  2021-05-20  8:34                         ` Martin Liška
  0 siblings, 1 reply; 16+ messages in thread
From: Marco Elver @ 2021-05-19 15:05 UTC (permalink / raw)
  To: Martin Liška
  Cc: Mark Rutland, Peter Zijlstra, Nick Desaulniers, Josh Poimboeuf,
	Will Deacon, Jose E. Marchesi, Paul E. McKenney, Ard Biesheuvel,
	Catalin Marinas, linux-toolchains

On Wed, 19 May 2021 at 17:02, Martin Liška <mliska@suse.cz> wrote:
> On 5/19/21 4:04 PM, Marco Elver wrote:
> > +Cc Martin, who helped us last time with no_sanitize issues in GCC.
> >
> > Martin, as far as we're aware there's no
> > __attribute__((no_sanitize_coverage)) for GCC -- is it possible to
> > implement this? Some context below. Thank you.
>
> Yes, I've just implemented the attribute and I'm going to send it to
> the gcc-patches mailing list tomorrow.

Very nice, thank you!

-- Marco

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Linux Plumbers Conf 2021
  2021-05-19 15:05                       ` Marco Elver
@ 2021-05-20  8:34                         ` Martin Liška
  0 siblings, 0 replies; 16+ messages in thread
From: Martin Liška @ 2021-05-20  8:34 UTC (permalink / raw)
  To: Marco Elver
  Cc: Mark Rutland, Peter Zijlstra, Nick Desaulniers, Josh Poimboeuf,
	Will Deacon, Jose E. Marchesi, Paul E. McKenney, Ard Biesheuvel,
	Catalin Marinas, linux-toolchains

On 5/19/21 5:05 PM, Marco Elver wrote:
> On Wed, 19 May 2021 at 17:02, Martin Liška <mliska@suse.cz> wrote:
>> On 5/19/21 4:04 PM, Marco Elver wrote:
>>> +Cc Martin, who helped us last time with no_sanitize issues in GCC.
>>>
>>> Martin, as far as we're aware there's no
>>> __attribute__((no_sanitize_coverage)) for GCC -- is it possible to
>>> implement this? Some context below. Thank you.
>>
>> Yes, I've just implemented the attribute and I'm going to send it to
>> the gcc-patches mailing list tomorrow.
> 
> Very nice, thank you!

You're welcome.

The patch has been just sent here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570840.html

Martin

> 
> -- Marco
> 


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Linux Plumbers Conf 2021
       [not found] ` <20210518121447.GB7914@willie-the-truck>
       [not found]   ` <20210518124311.r4fwv6lfz3erkqnb@treble>
@ 2021-06-16 23:01   ` Nick Desaulniers
  2021-06-24 20:35     ` Nick Desaulniers
  1 sibling, 1 reply; 16+ messages in thread
From: Nick Desaulniers @ 2021-06-16 23:01 UTC (permalink / raw)
  To: Will Deacon
  Cc: Jose E. Marchesi, Paul E. McKenney, Josh Poimboeuf,
	Peter Zijlstra, Ard Biesheuvel, Catalin Marinas, Mark Rutland,
	linux-toolchains

+ linux-toolchains

On Tue, May 18, 2021 at 5:14 AM Will Deacon <will@kernel.org> wrote:
>
> Hi Nick,
>
> [+cc relevant folks]
>
> (sorry this is so late)
>
> On Tue, May 04, 2021 at 10:38:09AM -0700, Nick Desaulniers wrote:
> > This year the Linux Plumbers Conference (https://linuxplumbersconf.org) will
> > be fully virtual, and will happen from September 20-24th 2021.
> >
> > As part of the event, we are organizing a `Toolchains and Kernel
> > Micro-conference' devoted to discuss specific topics involving kernel and
> > toolchain.  It will cover both the GNU Toolchain and LLVM.
> >
> > As in previous years, the emphasis will be in discussing specific topics that
> > require collaboration/interaction between the kernel and the toolchain chaps.
> > Examples of topics are wrapping of syscalls, specific features in the
> > compiler/linker/etc that are used by the kernel, desired optimizations,
> > features to alleviate security concerns on the kernel side, and the like.
> >
> > In order to get the Micro-Conference accepted we need to provide a list of
> > both topics and prospective attendants, so that's why I am reaching out to you
> > asking for:
> >
> > 1) Topics your project may want to discuss with the kernel hackers, during the
> >    event.
> >
> > 2) Whether you are willing to contribute and/or participate in the
> >    micro-conference.
> >
> > Please let us know @ jemarch@gnu.org & ndesaulniers@google.com.
>
> If it's not too late, I'd definitely be interested in a discussion around
> objtool support for arm64. Specifically, I would very much like us _not_
> to have a hard dependency on objtool and instead treat it as a binary
> linter of sorts. However, this likely requires help from the toolchain
> where some of the jobs which are performed by objtool on x86 today now
> need to be done by the compiler/linker for arm64.
>
> I don't have a good handle on exactly what is needed and whether there's
> any appetite from the toolchain developers to implement this, so it would
> be very helpful to kick that discussion off.
>
> Will



-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Linux Plumbers Conf 2021
  2021-06-16 23:01   ` Nick Desaulniers
@ 2021-06-24 20:35     ` Nick Desaulniers
  2021-06-24 20:37       ` Nick Desaulniers
  0 siblings, 1 reply; 16+ messages in thread
From: Nick Desaulniers @ 2021-06-24 20:35 UTC (permalink / raw)
  To: Will Deacon, Josh Poimboeuf, Julien Thierry, Bill Wendling
  Cc: Jose E. Marchesi, Paul E. McKenney, Peter Zijlstra,
	Ard Biesheuvel, Catalin Marinas, Mark Rutland, linux-toolchains

On Wed, Jun 16, 2021 at 4:01 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> + linux-toolchains
>
> On Tue, May 18, 2021 at 5:14 AM Will Deacon <will@kernel.org> wrote:
> >
> > Hi Nick,
> >
> > [+cc relevant folks]
> >
> > (sorry this is so late)
> >
> > On Tue, May 04, 2021 at 10:38:09AM -0700, Nick Desaulniers wrote:
> > > This year the Linux Plumbers Conference (https://linuxplumbersconf.org) will
> > > be fully virtual, and will happen from September 20-24th 2021.
> > >
> > > As part of the event, we are organizing a `Toolchains and Kernel
> > > Micro-conference' devoted to discuss specific topics involving kernel and
> > > toolchain.  It will cover both the GNU Toolchain and LLVM.
> > >
> > > As in previous years, the emphasis will be in discussing specific topics that
> > > require collaboration/interaction between the kernel and the toolchain chaps.
> > > Examples of topics are wrapping of syscalls, specific features in the
> > > compiler/linker/etc that are used by the kernel, desired optimizations,
> > > features to alleviate security concerns on the kernel side, and the like.
> > >
> > > In order to get the Micro-Conference accepted we need to provide a list of
> > > both topics and prospective attendants, so that's why I am reaching out to you
> > > asking for:
> > >
> > > 1) Topics your project may want to discuss with the kernel hackers, during the
> > >    event.
> > >
> > > 2) Whether you are willing to contribute and/or participate in the
> > >    micro-conference.
> > >
> > > Please let us know @ jemarch@gnu.org & ndesaulniers@google.com.
> >
> > If it's not too late, I'd definitely be interested in a discussion around
> > objtool support for arm64. Specifically, I would very much like us _not_
> > to have a hard dependency on objtool and instead treat it as a binary
> > linter of sorts. However, this likely requires help from the toolchain
> > where some of the jobs which are performed by objtool on x86 today now
> > need to be done by the compiler/linker for arm64.
> >
> > I don't have a good handle on exactly what is needed and whether there's
> > any appetite from the toolchain developers to implement this, so it would
> > be very helpful to kick that discussion off.

Hi Will, Josh, Julien, and Bill,
Our MC has been formally accepted:
https://www.linuxplumbersconf.org/blog/2021/index.php/2021/06/21/toolchains-and-kernel-microconference-accepted-into-2021-linux-plumbers-conference/

Would you mind please submitting a formal talk proposal at:
https://www.linuxplumbersconf.org/event/11/abstracts/

In the bottom right, click "Submit new proposal" then make sure to
select "Toolchains and Kernel" under the Track dropdown.

The Content field will be what's shown to attendees.  We'd like to
close our CFP by August 14th, 2021.

-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Linux Plumbers Conf 2021
  2021-06-24 20:35     ` Nick Desaulniers
@ 2021-06-24 20:37       ` Nick Desaulniers
  2021-06-28 17:59         ` Will Deacon
  0 siblings, 1 reply; 16+ messages in thread
From: Nick Desaulniers @ 2021-06-24 20:37 UTC (permalink / raw)
  To: Will Deacon, Josh Poimboeuf, Bill Wendling, Julien Thierry,
	julien.thierry
  Cc: Jose E. Marchesi, Paul E. McKenney, Peter Zijlstra,
	Ard Biesheuvel, Catalin Marinas, Mark Rutland, linux-toolchains

+ Julien (from .mailmap, got bounceback on the @redhat email addr)

On Thu, Jun 24, 2021 at 1:35 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Wed, Jun 16, 2021 at 4:01 PM Nick Desaulniers
> <ndesaulniers@google.com> wrote:
> >
> > + linux-toolchains
> >
> > On Tue, May 18, 2021 at 5:14 AM Will Deacon <will@kernel.org> wrote:
> > >
> > > Hi Nick,
> > >
> > > [+cc relevant folks]
> > >
> > > (sorry this is so late)
> > >
> > > On Tue, May 04, 2021 at 10:38:09AM -0700, Nick Desaulniers wrote:
> > > > This year the Linux Plumbers Conference (https://linuxplumbersconf.org) will
> > > > be fully virtual, and will happen from September 20-24th 2021.
> > > >
> > > > As part of the event, we are organizing a `Toolchains and Kernel
> > > > Micro-conference' devoted to discuss specific topics involving kernel and
> > > > toolchain.  It will cover both the GNU Toolchain and LLVM.
> > > >
> > > > As in previous years, the emphasis will be in discussing specific topics that
> > > > require collaboration/interaction between the kernel and the toolchain chaps.
> > > > Examples of topics are wrapping of syscalls, specific features in the
> > > > compiler/linker/etc that are used by the kernel, desired optimizations,
> > > > features to alleviate security concerns on the kernel side, and the like.
> > > >
> > > > In order to get the Micro-Conference accepted we need to provide a list of
> > > > both topics and prospective attendants, so that's why I am reaching out to you
> > > > asking for:
> > > >
> > > > 1) Topics your project may want to discuss with the kernel hackers, during the
> > > >    event.
> > > >
> > > > 2) Whether you are willing to contribute and/or participate in the
> > > >    micro-conference.
> > > >
> > > > Please let us know @ jemarch@gnu.org & ndesaulniers@google.com.
> > >
> > > If it's not too late, I'd definitely be interested in a discussion around
> > > objtool support for arm64. Specifically, I would very much like us _not_
> > > to have a hard dependency on objtool and instead treat it as a binary
> > > linter of sorts. However, this likely requires help from the toolchain
> > > where some of the jobs which are performed by objtool on x86 today now
> > > need to be done by the compiler/linker for arm64.
> > >
> > > I don't have a good handle on exactly what is needed and whether there's
> > > any appetite from the toolchain developers to implement this, so it would
> > > be very helpful to kick that discussion off.
>
> Hi Will, Josh, Julien, and Bill,
> Our MC has been formally accepted:
> https://www.linuxplumbersconf.org/blog/2021/index.php/2021/06/21/toolchains-and-kernel-microconference-accepted-into-2021-linux-plumbers-conference/
>
> Would you mind please submitting a formal talk proposal at:
> https://www.linuxplumbersconf.org/event/11/abstracts/
>
> In the bottom right, click "Submit new proposal" then make sure to
> select "Toolchains and Kernel" under the Track dropdown.
>
> The Content field will be what's shown to attendees.  We'd like to
> close our CFP by August 14th, 2021.
>
> --
> Thanks,
> ~Nick Desaulniers



-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Linux Plumbers Conf 2021
  2021-06-24 20:37       ` Nick Desaulniers
@ 2021-06-28 17:59         ` Will Deacon
  0 siblings, 0 replies; 16+ messages in thread
From: Will Deacon @ 2021-06-28 17:59 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: Josh Poimboeuf, Bill Wendling, Julien Thierry, julien.thierry,
	Jose E. Marchesi, Paul E. McKenney, Peter Zijlstra,
	Ard Biesheuvel, Catalin Marinas, Mark Rutland, linux-toolchains

Hi Nick,

On Thu, Jun 24, 2021 at 01:37:22PM -0700, Nick Desaulniers wrote:
> On Thu, Jun 24, 2021 at 1:35 PM Nick Desaulniers
> <ndesaulniers@google.com> wrote:
> > On Wed, Jun 16, 2021 at 4:01 PM Nick Desaulniers
> > <ndesaulniers@google.com> wrote:
> > > On Tue, May 18, 2021 at 5:14 AM Will Deacon <will@kernel.org> wrote:
> > > > If it's not too late, I'd definitely be interested in a discussion around
> > > > objtool support for arm64. Specifically, I would very much like us _not_
> > > > to have a hard dependency on objtool and instead treat it as a binary
> > > > linter of sorts. However, this likely requires help from the toolchain
> > > > where some of the jobs which are performed by objtool on x86 today now
> > > > need to be done by the compiler/linker for arm64.
> > > >
> > > > I don't have a good handle on exactly what is needed and whether there's
> > > > any appetite from the toolchain developers to implement this, so it would
> > > > be very helpful to kick that discussion off.
> >
> > Hi Will, Josh, Julien, and Bill,
> > Our MC has been formally accepted:
> > https://www.linuxplumbersconf.org/blog/2021/index.php/2021/06/21/toolchains-and-kernel-microconference-accepted-into-2021-linux-plumbers-conference/
> >
> > Would you mind please submitting a formal talk proposal at:
> > https://www.linuxplumbersconf.org/event/11/abstracts/
> >
> > In the bottom right, click "Submit new proposal" then make sure to
> > select "Toolchains and Kernel" under the Track dropdown.
> >
> > The Content field will be what's shown to attendees.  We'd like to
> > close our CFP by August 14th, 2021.

I just submitted something for "objtool on arm64".

Will

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, back to index

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CAKwvOdm-Vb2BGRCmtYCh5JcGkM+XedzSMdNr8kQLbY4y_85EvA@mail.gmail.com>
     [not found] ` <20210518121447.GB7914@willie-the-truck>
     [not found]   ` <20210518124311.r4fwv6lfz3erkqnb@treble>
2021-05-18 12:48     ` Linux Plumbers Conf 2021 Josh Poimboeuf
2021-05-18 13:21       ` Peter Zijlstra
2021-05-18 16:57         ` Nick Desaulniers
2021-05-18 20:03           ` Peter Zijlstra
2021-05-18 20:15             ` Nick Desaulniers
2021-05-19  9:32             ` Mark Rutland
2021-05-19 10:19               ` Marco Elver
2021-05-19 11:56                 ` Mark Rutland
2021-05-19 14:04                   ` Marco Elver
2021-05-19 15:02                     ` Martin Liška
2021-05-19 15:05                       ` Marco Elver
2021-05-20  8:34                         ` Martin Liška
2021-06-16 23:01   ` Nick Desaulniers
2021-06-24 20:35     ` Nick Desaulniers
2021-06-24 20:37       ` Nick Desaulniers
2021-06-28 17:59         ` Will Deacon

Linux-Toolchains Archive at lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-toolchains/0 linux-toolchains/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-toolchains linux-toolchains/ https://lore.kernel.org/linux-toolchains \
		linux-toolchains@vger.kernel.org
	public-inbox-index linux-toolchains

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-toolchains


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git