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
