Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: B5BfdzVELFeXuc0ei0jP881xpC2yejmY7xv0AUR+cY2ZcRkEFWPEAFIL5JBjOYxQX4gkYI+XZj
 hCm74We0GaoQ==
IronPort-SDR: av0sKWOYau6s6d1swTN7BWeVgPq3oopzECLt1zc/06mbPLQKb4uSXX12ehtGidmFX4YQT9Fmsz
 F2r7MAjtiJfw==
Subject: Re: [PATCH 2/2] sigaction.2: wfix - Clarify si_addr description.
To:     Borislav Petkov <bp@alien8.de>
Cc:     linux-man@vger.kernel.org,
        Alejandro Colomar <alx.manpages@gmail.com>,
        Michael Kerrisk <mtk.manpages@gmail.com>,
        Andy Lutomirski <luto@kernel.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Florian Weimer <fweimer@redhat.com>,
        "H.J. Lu" <hjl.tools@gmail.com>, linux-kernel@vger.kernel.org,
        linux-api@vger.kernel.org
References: <20210226172634.26905-1-yu-cheng.yu@intel.com>
 <20210226172634.26905-3-yu-cheng.yu@intel.com>
 <20210308212936.GD12548@zn.tnic>
From:   "Yu, Yu-cheng" <yu-cheng.yu@intel.com>
Message-ID: <40c3c4cc-e135-1355-51ee-4d0f16e47e71@intel.com>
Date:   Mon, 8 Mar 2021 13:46:07 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <20210308212936.GD12548@zn.tnic>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

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