* [PATCH 0/2] sigaction.2: Updates for SEGV_CPERR @ 2021-02-26 17:26 Yu-cheng Yu 2021-02-26 17:26 ` [PATCH 1/2] sigaction.2: Add SEGV_CPERR Yu-cheng Yu 2021-02-26 17:26 ` [PATCH 2/2] sigaction.2: wfix - Clarify si_addr description Yu-cheng Yu 0 siblings, 2 replies; 8+ messages in thread From: Yu-cheng Yu @ 2021-02-26 17:26 UTC (permalink / raw) To: linux-man; +Cc: Yu-cheng Yu Control-flow Enforcement [1] [2] introduces a new control-protection fault, which is triggered by a branch instruction (call, ret, or jmp) violating branch-enforcement rules. When the signal is delivered, si_code is set to SEGV_CPERR. Add the code to sigaction.2, and while at it, clarify when si_addr is set. [1] Intel 64 and IA-32 Architectures Software Developer's Manual: https://software.intel.com/en-us/download/intel-64-and-ia-32- architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4 [2] CET Shadow Stack patches v21: https://lkml.kernel.org/r/20210217222730.15819-1-yu-cheng.yu@intel.com/ https://lkml.kernel.org/r/20210217223135.16790-1-yu-cheng.yu@intel.com/ Yu-cheng Yu (2): sigaction.2: Add SEGV_CPERR sigaction.2: wfix - Clarify si_addr description. man2/sigaction.2 | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) -- 2.21.0 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 1/2] sigaction.2: Add SEGV_CPERR 2021-02-26 17:26 [PATCH 0/2] sigaction.2: Updates for SEGV_CPERR Yu-cheng Yu @ 2021-02-26 17:26 ` Yu-cheng Yu 2021-02-26 17:26 ` [PATCH 2/2] sigaction.2: wfix - Clarify si_addr description Yu-cheng Yu 1 sibling, 0 replies; 8+ messages in thread From: Yu-cheng Yu @ 2021-02-26 17:26 UTC (permalink / raw) To: linux-man Cc: Yu-cheng Yu, Alejandro Colomar, Michael Kerrisk, Andy Lutomirski, Borislav Petkov, Dave Hansen, Florian Weimer, H.J. Lu, linux-kernel, linux-api When a branch instruction (i.e. call/ret/jmp) triggers a control-protection fault, si_code is set to SEGV_CPERR. Add the new si_code to sigaction.2. Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com> Cc: Alejandro Colomar <alx.manpages@gmail.com> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Florian Weimer <fweimer@redhat.com> Cc: "H.J. Lu" <hjl.tools@gmail.com> Cc: linux-kernel@vger.kernel.org Cc: linux-api@vger.kenel.org Link: https://lore.kernel.org/linux-api/20210217222730.15819-7-yu-cheng.yu@intel.com/ --- man2/sigaction.2 | 3 +++ 1 file changed, 3 insertions(+) diff --git a/man2/sigaction.2 b/man2/sigaction.2 index cc183198d..49a30f11e 100644 --- a/man2/sigaction.2 +++ b/man2/sigaction.2 @@ -737,6 +737,9 @@ See .BR pkeys (7). The protection key which applied to this access is available via .IR si_pkey . +.TP +.B SEGV_CPERR +A branch instruction (call, ret, or jmp) triggered a control-protection fault. .RE .PP The following values can be placed in -- 2.21.0 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH 2/2] sigaction.2: wfix - Clarify si_addr description. 2021-02-26 17:26 [PATCH 0/2] sigaction.2: Updates for SEGV_CPERR Yu-cheng Yu 2021-02-26 17:26 ` [PATCH 1/2] sigaction.2: Add SEGV_CPERR Yu-cheng Yu @ 2021-02-26 17:26 ` Yu-cheng Yu 2021-03-08 21:30 ` Borislav Petkov 1 sibling, 1 reply; 8+ messages in thread From: Yu-cheng Yu @ 2021-02-26 17:26 UTC (permalink / raw) To: linux-man Cc: Yu-cheng Yu, Alejandro Colomar, Michael Kerrisk, Andy Lutomirski, Borislav Petkov, Dave Hansen, Florian Weimer, H.J. Lu, linux-kernel, linux-api SIGSEGV fills si_addr only for memory access faults. Add a note to clarify. Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com> Cc: Alejandro Colomar <alx.manpages@gmail.com> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Florian Weimer <fweimer@redhat.com> Cc: "H.J. Lu" <hjl.tools@gmail.com> Cc: linux-kernel@vger.kernel.org Cc: linux-api@vger.kenel.org Link: https://lore.kernel.org/linux-api/20210217222730.15819-7-yu-cheng.yu@intel.com/ --- man2/sigaction.2 | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/man2/sigaction.2 b/man2/sigaction.2 index 49a30f11e..bea884a23 100644 --- a/man2/sigaction.2 +++ b/man2/sigaction.2 @@ -467,7 +467,7 @@ and .BR SIGTRAP fill in .I si_addr -with the address of the fault. +with the address of the fault (see notes). On some architectures, these signals also fill in the .I si_trapno @@ -955,6 +955,11 @@ It is not possible to block .IR sa_mask ). Attempts to do so are silently ignored. .PP +In a +.B SIGSEGV, +if the fault is a memory access fault, si_addr is filled with the address +causing the fault, otherwise it is not filled. +.PP See .BR sigsetops (3) for details on manipulating signal sets. -- 2.21.0 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] sigaction.2: wfix - Clarify si_addr description. 2021-02-26 17:26 ` [PATCH 2/2] sigaction.2: wfix - Clarify si_addr description Yu-cheng Yu @ 2021-03-08 21:30 ` Borislav Petkov 2021-03-08 21:46 ` Yu, Yu-cheng 0 siblings, 1 reply; 8+ messages in thread From: Borislav Petkov @ 2021-03-08 21:30 UTC (permalink / raw) To: Yu-cheng Yu Cc: linux-man, Alejandro Colomar, Michael Kerrisk, Andy Lutomirski, Dave Hansen, Florian Weimer, H.J. Lu, linux-kernel, linux-api On Fri, Feb 26, 2021 at 09:26:34AM -0800, Yu-cheng Yu wrote: > SIGSEGV fills si_addr only for memory access faults. Add a note to clarify. > > Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com> > Cc: Alejandro Colomar <alx.manpages@gmail.com> > Cc: Michael Kerrisk <mtk.manpages@gmail.com> > Cc: Andy Lutomirski <luto@kernel.org> > Cc: Borislav Petkov <bp@alien8.de> > Cc: Dave Hansen <dave.hansen@linux.intel.com> > Cc: Florian Weimer <fweimer@redhat.com> > Cc: "H.J. Lu" <hjl.tools@gmail.com> > Cc: linux-kernel@vger.kernel.org > Cc: linux-api@vger.kenel.org > Link: https://lore.kernel.org/linux-api/20210217222730.15819-7-yu-cheng.yu@intel.com/ > --- > man2/sigaction.2 | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/man2/sigaction.2 b/man2/sigaction.2 > index 49a30f11e..bea884a23 100644 > --- a/man2/sigaction.2 > +++ b/man2/sigaction.2 > @@ -467,7 +467,7 @@ and > .BR SIGTRAP > fill in > .I si_addr > -with the address of the fault. > +with the address of the fault (see notes). > On some architectures, > these signals also fill in the > .I si_trapno > @@ -955,6 +955,11 @@ It is not possible to block > .IR sa_mask ). > Attempts to do so are silently ignored. > .PP > +In a > +.B SIGSEGV, > +if the fault is a memory access fault, si_addr is filled with the address > +causing the fault, otherwise it is not filled. "... otherwise it is uninitialized." or "zeroed" or whatever... And I'm having trouble figuring out why do you need to clarify this? Because of this sentence: * SIGILL, SIGFPE, SIGSEGV, SIGBUS, and SIGTRAP fill in si_addr with the address of the fault. On some architectures, these signals also fill in the si_trapno field. ? If so, did you audit all architectures whether si_addr is populated only on memory access faults or is this something POSIX dictates or what's up? Because the sigaction(2) manpage is arch-agnostic and this is a rather strong assertion. What am I missing? Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] sigaction.2: wfix - Clarify si_addr description. 2021-03-08 21:30 ` Borislav Petkov @ 2021-03-08 21:46 ` Yu, Yu-cheng 2021-03-09 14:31 ` Borislav Petkov 0 siblings, 1 reply; 8+ messages in thread From: Yu, Yu-cheng @ 2021-03-08 21:46 UTC (permalink / raw) To: Borislav Petkov Cc: linux-man, Alejandro Colomar, Michael Kerrisk, Andy Lutomirski, Dave Hansen, Florian Weimer, H.J. Lu, linux-kernel, linux-api On 3/8/2021 1:30 PM, Borislav Petkov wrote: > On Fri, Feb 26, 2021 at 09:26:34AM -0800, Yu-cheng Yu wrote: >> SIGSEGV fills si_addr only for memory access faults. Add a note to clarify. >> >> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com> >> Cc: Alejandro Colomar <alx.manpages@gmail.com> >> Cc: Michael Kerrisk <mtk.manpages@gmail.com> >> Cc: Andy Lutomirski <luto@kernel.org> >> Cc: Borislav Petkov <bp@alien8.de> >> Cc: Dave Hansen <dave.hansen@linux.intel.com> >> Cc: Florian Weimer <fweimer@redhat.com> >> Cc: "H.J. Lu" <hjl.tools@gmail.com> >> Cc: linux-kernel@vger.kernel.org >> Cc: linux-api@vger.kenel.org >> Link: https://lore.kernel.org/linux-api/20210217222730.15819-7-yu-cheng.yu@intel.com/ >> --- >> man2/sigaction.2 | 7 ++++++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/man2/sigaction.2 b/man2/sigaction.2 >> index 49a30f11e..bea884a23 100644 >> --- a/man2/sigaction.2 >> +++ b/man2/sigaction.2 >> @@ -467,7 +467,7 @@ and >> .BR SIGTRAP >> fill in >> .I si_addr >> -with the address of the fault. >> +with the address of the fault (see notes). >> On some architectures, >> these signals also fill in the >> .I si_trapno >> @@ -955,6 +955,11 @@ It is not possible to block >> .IR sa_mask ). >> Attempts to do so are silently ignored. >> .PP >> +In a >> +.B SIGSEGV, >> +if the fault is a memory access fault, si_addr is filled with the address >> +causing the fault, otherwise it is not filled. > > "... otherwise it is uninitialized." or "zeroed" or whatever... > > And I'm having trouble figuring out why do you need to clarify this? > > Because of this sentence: > > * SIGILL, SIGFPE, SIGSEGV, SIGBUS, and SIGTRAP fill in si_addr with the address > of the fault. On some architectures, these signals also fill in the si_trapno > field. > > ? I think the sentence above is vague, but probably for the reason that each arch is different. Maybe this patch is unnecessary and can be dropped? > > If so, did you audit all architectures whether si_addr is populated only > on memory access faults or is this something POSIX dictates or what's > up? Because the sigaction(2) manpage is arch-agnostic and this is a > rather strong assertion. > > What am I missing? > > Thx. > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] sigaction.2: wfix - Clarify si_addr description. 2021-03-08 21:46 ` Yu, Yu-cheng @ 2021-03-09 14:31 ` Borislav Petkov [not found] ` <CACKs7VBLnQTc_RgnXk8X-XgVRvR5_uXY0wL0snW7P5iDjpb8fA@mail.gmail.com> 0 siblings, 1 reply; 8+ messages in thread From: Borislav Petkov @ 2021-03-09 14:31 UTC (permalink / raw) To: Yu, Yu-cheng Cc: linux-man, Alejandro Colomar, Michael Kerrisk, Andy Lutomirski, Dave Hansen, Florian Weimer, H.J. Lu, linux-kernel, linux-api On Mon, Mar 08, 2021 at 01:46:07PM -0800, Yu, Yu-cheng wrote: > I think the sentence above is vague, but probably for the reason that each > arch is different. Maybe this patch is unnecessary and can be dropped? Maybe. If you want to clarify it, you should audit every arch. But what would that bring? IOW, is it that important to specify when si_addr is populated and when not...? I don't know of an example but I'm no userspace programmer anyway, to know when this info would be beneficial... -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <CACKs7VBLnQTc_RgnXk8X-XgVRvR5_uXY0wL0snW7P5iDjpb8fA@mail.gmail.com>]
* Re: [PATCH 2/2] sigaction.2: wfix - Clarify si_addr description. [not found] ` <CACKs7VBLnQTc_RgnXk8X-XgVRvR5_uXY0wL0snW7P5iDjpb8fA@mail.gmail.com> @ 2021-03-11 17:33 ` Yu, Yu-cheng 2021-03-12 12:55 ` Stefan Puiu 0 siblings, 1 reply; 8+ messages in thread From: Yu, Yu-cheng @ 2021-03-11 17:33 UTC (permalink / raw) To: Stefan Puiu, Borislav Petkov Cc: lnx-man, Alejandro Colomar, Michael Kerrisk, Andy Lutomirski, Dave Hansen, Florian Weimer, H.J. Lu, linux-kernel, linux-api On 3/11/2021 9:17 AM, Stefan Puiu wrote: > Hi, > > My 2 cents below. > > On Tue, Mar 9, 2021, 16:33 Borislav Petkov <bp@alien8.de > <mailto:bp@alien8.de>> wrote: > > On Mon, Mar 08, 2021 at 01:46:07PM -0800, Yu, Yu-cheng wrote: > > I think the sentence above is vague, but probably for the reason > that each > > arch is different. Maybe this patch is unnecessary and can be > dropped? > > Maybe. > > If you want to clarify it, you should audit every arch. But what > would that bring? IOW, is it that important to specify when si_addr > is populated and when not...? I don't know of an example but I'm > no userspace programmer anyway, to know when this info would be > beneficial... > > > I've worked on projects where the SIGSEGV sig handler would also print > si_addr. When diagnosing a crash, the address that triggered the fault > is useful to know. If you can't reproduce the crash in a debugger, or > there's no core dump, at least you have an idea if it's a NULL pointer > dereference or some naked pointer dereferencing. So I think it's useful > to know when si_addr can be used to infer such information and when not. At least for x86, the faulting ip is already in ucontext, and si_addr is mostly the memory address being accessed if that was the reason of the fault (i.e. the memory is not supposed to be accessed). That way, the signal handler has both the instruction pointer and the memory address. For shadow stack violation, for example, it is not because the memory being accessed; it is the instruction itself causing the violation. It is unnecessary to duplicate the ip in si_addr. Setting si_addr to zero also indicates this is not a memory type fault. -- Yu-cheng ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] sigaction.2: wfix - Clarify si_addr description. 2021-03-11 17:33 ` Yu, Yu-cheng @ 2021-03-12 12:55 ` Stefan Puiu 0 siblings, 0 replies; 8+ messages in thread From: Stefan Puiu @ 2021-03-12 12:55 UTC (permalink / raw) To: Yu, Yu-cheng Cc: Borislav Petkov, lnx-man, Alejandro Colomar, Michael Kerrisk, Andy Lutomirski, Dave Hansen, Florian Weimer, H.J. Lu, linux-kernel, linux-api On Thu, Mar 11, 2021 at 7:33 PM Yu, Yu-cheng <yu-cheng.yu@intel.com> wrote: > > On 3/11/2021 9:17 AM, Stefan Puiu wrote: > > Hi, > > > > My 2 cents below. > > > > On Tue, Mar 9, 2021, 16:33 Borislav Petkov <bp@alien8.de > > <mailto:bp@alien8.de>> wrote: > > > > On Mon, Mar 08, 2021 at 01:46:07PM -0800, Yu, Yu-cheng wrote: > > > I think the sentence above is vague, but probably for the reason > > that each > > > arch is different. Maybe this patch is unnecessary and can be > > dropped? > > > > Maybe. > > > > If you want to clarify it, you should audit every arch. But what > > would that bring? IOW, is it that important to specify when si_addr > > is populated and when not...? I don't know of an example but I'm > > no userspace programmer anyway, to know when this info would be > > beneficial... > > > > > > I've worked on projects where the SIGSEGV sig handler would also print > > si_addr. When diagnosing a crash, the address that triggered the fault > > is useful to know. If you can't reproduce the crash in a debugger, or > > there's no core dump, at least you have an idea if it's a NULL pointer > > dereference or some naked pointer dereferencing. So I think it's useful > > to know when si_addr can be used to infer such information and when not. > > At least for x86, the faulting ip is already in ucontext, and si_addr is > mostly the memory address being accessed if that was the reason of the > fault (i.e. the memory is not supposed to be accessed). That way, the > signal handler has both the instruction pointer and the memory address. Interesting that you mention ucontext. I think the ability to fetch the IP from it is not that well documented. See for example the sigaction man page (https://man7.org/linux/man-pages/man2/sigaction.2.html): Further information about the ucontext_t structure can be found in getcontext(3) and signal(7). Commonly, the handler function doesn't make any use of the third argument. Michael's book ("The Linux Programming Interface") has similar text on ucontext ("This information is rarely used in signal handlers, so we don’t go into further details"). I could find one example on google for fetching the IP at https://www.oracle.com/technical-resources/articles/it-infrastructure/dev-signal-handlers-studio.html, but it pertains to SPARC. Also I've found one older of our projects that uses this, and it seems each architecture has its own layout (the code handles ppc, mips and x86-64). Is this documented somewhere? Outside of the arch-specific kernel definition of the uc_mcontext member in the code, I mean :). Thanks, Stefan. > > For shadow stack violation, for example, it is not because the memory > being accessed; it is the instruction itself causing the violation. It > is unnecessary to duplicate the ip in si_addr. Setting si_addr to zero > also indicates this is not a memory type fault. > > -- > Yu-cheng ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-03-12 12:56 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-02-26 17:26 [PATCH 0/2] sigaction.2: Updates for SEGV_CPERR Yu-cheng Yu 2021-02-26 17:26 ` [PATCH 1/2] sigaction.2: Add SEGV_CPERR Yu-cheng Yu 2021-02-26 17:26 ` [PATCH 2/2] sigaction.2: wfix - Clarify si_addr description Yu-cheng Yu 2021-03-08 21:30 ` Borislav Petkov 2021-03-08 21:46 ` Yu, Yu-cheng 2021-03-09 14:31 ` Borislav Petkov [not found] ` <CACKs7VBLnQTc_RgnXk8X-XgVRvR5_uXY0wL0snW7P5iDjpb8fA@mail.gmail.com> 2021-03-11 17:33 ` Yu, Yu-cheng 2021-03-12 12:55 ` Stefan Puiu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).