Linux Plumbers Conf 2021

Linux Plumbers Conf 2021

[Nick Desaulniers]

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 me know @ ndesaulniers@google.com.

-- 
Thanks,
~Nick Desaulniers

Re: Linux Plumbers Conf 2021

[Nick Desaulniers]

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.

On Tue, May 4, 2021 at 10:34 AM Nick Desaulniers
<ndesaulniers@google.com> 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 me know @ ndesaulniers@google.com.
>
> --
> Thanks,
> ~Nick Desaulniers



-- 
Thanks,
~Nick Desaulniers

Re: Linux Plumbers Conf 2021

[Josh Poimboeuf]

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

Re: Linux Plumbers Conf 2021

[Peter Zijlstra]

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.

Re: Linux Plumbers Conf 2021

[Nick Desaulniers]

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

Re: Linux Plumbers Conf 2021

[Peter Zijlstra]

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."

Re: Linux Plumbers Conf 2021

[Nick Desaulniers]

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

Re: Linux Plumbers Conf 2021

[Mark Rutland]

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.

Re: Linux Plumbers Conf 2021

[Marco Elver]

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

Re: Linux Plumbers Conf 2021

[Mark Rutland]

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.

Re: Linux Plumbers Conf 2021

[Marco Elver]

+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

Re: Linux Plumbers Conf 2021

[Martin Liška]

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
> 

Re: Linux Plumbers Conf 2021

[Marco Elver]

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

Re: Linux Plumbers Conf 2021

[Martin Liška]

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
> 

Re: Linux Plumbers Conf 2021

[Nick Desaulniers]

+ 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

Re: Linux Plumbers Conf 2021

[Nick Desaulniers]

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

Re: Linux Plumbers Conf 2021

[Nick Desaulniers]

+ 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

Re: Linux Plumbers Conf 2021

[Will Deacon]

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