linux-kernel - Re: [PATCH 2/2] sigaction.2: wfix

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 11 Mar 2021 09:33:16 -0800
From:   "Yu, Yu-cheng" <yu-cheng.yu@...el.com>
To:     Stefan Puiu <stefan.puiu@...il.com>, Borislav Petkov <bp@...en8.de>
Cc:     lnx-man <linux-man@...r.kernel.org>,
        Alejandro Colomar <alx.manpages@...il.com>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Florian Weimer <fweimer@...hat.com>,
        "H.J. Lu" <hjl.tools@...il.com>, linux-kernel@...r.kernel.org,
        linux-api@...r.kernel.org
Subject: Re: [PATCH 2/2] sigaction.2: wfix - Clarify si_addr description.

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@...en8.de 
> <mailto:bp@...en8.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