[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <299b3054-30d0-afa1-3503-2998b9742a28@csgroup.eu>
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
Powered by blists - more mailing lists