Re: [PATCH 0/5] Improve arm64 pkeys handling in signal delivery

[Kevin Brodsky <kevin.brodsky@arm.com>]

On 17/10/2024 17:48, Dave Martin wrote:
> On Thu, Oct 17, 2024 at 02:39:04PM +0100, Kevin Brodsky wrote:
>> This series is a follow-up to Joey's Permission Overlay Extension (POE)
>> series [1] that recently landed on mainline. The goal is to improve the
>> way we handle the register that governs which pkeys/POIndex are
>> accessible (POR_EL0) during signal delivery. As things stand, we may
>> unexpectedly fail to write the signal frame on the stack because POR_EL0
>> is not reset before the uaccess operations. See patch 3 for more details
>> and the main changes this series brings.
>>
>> A similar series landed recently for x86/MPK [2]; the present series
>> aims at aligning arm64 with x86. Worth noting: once the signal frame is
>> written, POR_EL0 is still set to POR_EL0_INIT, granting access to pkey 0
>> only. This means that a program that sets up an alternate signal stack
>> with a non-zero pkey will need some assembly trampoline to set POR_EL0
>> before invoking the real signal handler, as discussed here [3].
> This feels a bit bogus (though it's anyway orthogonal to this series).

I'm not very fond of this either. However I believe this is the correct
first step: bring arm64 in line with x86. Removing all restrictions
before uaccess and then setting POR_EL0 to POR_EL0_INIT enables
userspace to use any pkey for the alternate signal stack without an ABI
change, albeit not in a very comfortable way (if the pkey is not 0).

> Really, we want some way for userspace to tell the kernel what
> permissions to use for the alternate signal stack and signal handlers
> using it, and then honour that request consistently (just as we try to
> do for the main stack today).
>
> ss_flags is mostly unused... I wonder whether we could add something in
> there?  Or add a sigaltstack2()?

Yes, this would be sensible as a second step (backwards-compatible
extension). Exactly how that API would look like is not trivial though:
is the pkey implicitly derived from the pointer provided to
sigaltstack()? Is there a need to specify another pkey for code, or do
we just assume that the signal handler is only using code with pkey 0?
(Not a concern on x86 as MPK doesn't restrict execution.) Would be very
interested to hear opinions on this.

Kevin