linux-kernel - Re: [PATCH 4/4] powerpc/kuap: Make disabling KUAP at boottime optional

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

Date:   Thu, 22 Jun 2023 06:20:59 +0000
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     Nicholas Piggin <npiggin@...il.com>,
        Michael Ellerman <mpe@...erman.id.au>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH 4/4] powerpc/kuap: Make disabling KUAP at boottime
 optional

Le 06/06/2023 à 11:27, Nicholas Piggin a écrit :
> On Mon Jun 5, 2023 at 9:04 PM AEST, Christophe Leroy wrote:
>> It is possible to disable KUAP at boottime with 'nosmap' parameter.
>>
>> That is implemented with jump_label hence adds a 'nop' in front
>> of each open/close of userspace access.
>>
>>  From a security point of view it makes sence to disallow disabling
>> KUAP. And on processors like the 8xx where 'nop' is not seamless,
>> it saves a few cycles.
>>
>> So add a CONFIG item to make it optionnal.
> 
> I love counting cycles, but a CONFIG option for one nop... I think
> you have me beat.

Unlike most other powerpc, a nop on 8xx is one cycle. So if we can avoid 
it on hot pathes ....

> 
> Is that sustainable? What if instead of the static branch you patched in
> nops to the lock/unlock asm? AFAIKS there does not look like much (any?)
> C code in the kuap enabled branches.

Yes that's probably the solution at the end.

At the moment I'm struggling with UACCESS objtool validation and I think 
I will temporarily disable boottime 'nosmap' parameter for PPC32.

The problem is that with the static branch, objtool visits both branches 
but it does it independently for each branch, it is not able to match 
two static branches using the same key. So the result is that it detects 
UACCESS enable without UACCESS disable and vice-versa.

So the solution at the end will be to patch-out the mtspr, for the time 
being I'm just going to disable it completely for PPC32.

Christophe