* 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; 18+ 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] 18+ 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; 18+ 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] 18+ 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; 18+ 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] 18+ 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; 18+ 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] 18+ 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; 18+ 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] 18+ 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; 18+ 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] 18+ 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; 18+ 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] 18+ 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; 18+ 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] 18+ 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; 18+ 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] 18+ 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; 18+ 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] 18+ 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; 18+ 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] 18+ 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; 18+ 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] 18+ 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; 18+ 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] 18+ 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; 18+ 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] 18+ 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; 18+ 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] 18+ 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; 18+ 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] 18+ messages in thread
* Linux Plumbers Conf 2021 @ 2021-05-04 17:34 Nick Desaulniers 2021-06-24 20:31 ` Nick Desaulniers 0 siblings, 1 reply; 18+ messages in thread From: Nick Desaulniers @ 2021-05-04 17:34 UTC (permalink / raw) To: rust-for-linux 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Linux Plumbers Conf 2021 2021-05-04 17:34 Nick Desaulniers @ 2021-06-24 20:31 ` Nick Desaulniers 0 siblings, 0 replies; 18+ messages in thread From: Nick Desaulniers @ 2021-06-24 20:31 UTC (permalink / raw) To: rust-for-linux 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2021-06-28 17:59 UTC | newest]
Thread overview: 18+ 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
2021-05-04 17:34 Nick Desaulniers
2021-06-24 20:31 ` Nick Desaulniers
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.