linux-kernel - Re: [REVIEW][PATCH 7/9] signal/poewrpc: Specialize _exception

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b140e12e-e1fa-1878-16d0-531ffc821e6f@c-s.fr>
Date:   Fri, 21 Sep 2018 10:58:44 +0200
From:   Christophe LEROY <christophe.leroy@....fr>
To:     Stephen Rothwell <sfr@...b.auug.org.au>,
        "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
        Paul Mackerras <paulus@...ba.org>,
        linuxppc-dev@...ts.ozlabs.org
Subject: Re: [REVIEW][PATCH 7/9] signal/poewrpc: Specialize _exception_pkey
 for handling pkey exceptions



Le 21/09/2018 à 10:54, Stephen Rothwell a écrit :
> Hi Eric,
> 
> On Tue, 18 Sep 2018 19:58:48 +0200 "Eric W. Biederman" <ebiederm@...ssion.com> wrote:
>>
>> Now that _exception no longer calls _exception_pkey it is no longer
>> necessary to handle any signal with any si_code.  All pkey exceptions
>> are SIGSEGV with paired with SEGV_PKUERR.  So just handle
>> that case and remove the now unnecessary parameters from _exception_pkey.
>>
>> Signed-off-by: "Eric W. Biederman" <ebiederm@...ssion.com>
> 
> Looks fine to me (small query below).
> 
> Reviewed-by: Stephen Rothwell <sfr@...b.auug.org.au>

In the patch title, s/poewrpc/powerpc

> 
>>   	clear_siginfo(&info);
>> -	info.si_signo = signr;
>> -	info.si_code = code;
>> +	info.si_signo = SIGSEGV;
>> +	info.si_code = SEGV_PKUERR;
>>   	info.si_addr = (void __user *) addr;
>>   	info.si_pkey = key;
>>   
>> -	force_sig_info(signr, &info, current);
>> +	force_sig_info(info.si_signo, &info, current);
>                         ^^^^^^^^^^^^^
> Why not just SIGSEGV?
>