On Mon, Oct 21, 2024 at 04:30:04PM +0100, Catalin Marinas wrote: > On Mon, Oct 21, 2024 at 02:31:08PM +0100, Dave P 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]. > [...] > > Memory with a non-zero pkey cannot be used 100% portably, period, and > > having non-RW(X) permissions on pkey 0 at any time is also not > > portable, period. So I'm not sure that having libc magically guess > > what userspace's pkeys policy is supposed to be based on racily digging > > metadata out of /proc/self/maps or a cache of it etc. would be such a > > good idea. > > I agree that changing RWX overlay permission for pkey 0 to anything else > is a really bad idea. We can't prevent it but we shouldn't actively try > to work around it in the kernel either. With the current signal ABI, I > don't think we should support anything other than pkey 0 for the stack. > Since the user shouldn't change the pkey 0 RWX overlay permission > anyway, I don't think we should reset POR_EL0 _prior_ to writing the > signal frame. The best we can do is document it somewhere. > > So on patch 3 I'd only ensure that we have POR_EL0_INIT when invoking > the signal handler and not when performing the uaccess. If the uaccess > fails, we'd get a fatal SIGSEGV. The user may have got it already if it > made the stack read-only. Hmm, but based on what Kevin's saying, this would mean actively choosing a different ABI than what x86 is trying to get to. > Currently the primary use of pkeys is for W^X and signal stacks > shouldn't fall into this category. If we ever have a strong case for > non-zero pkeys on the signal stack, we'll need to look into some new > ABI. I'm not sure about SS_* flags though, I think the signal POR_EL0 > should be associated with the sigaction rather than the stack (the > latter would just be mapped by the user with the right pkey, the kernel > doesn't need to know which, only what POR_EL0 is needed by the handler). > > Until such case turns up, I'd not put any effort into ABI improvements. Kevin -- do you know what prompted x86 to want the pkey to be reset early in signal delivery? Perhaps such a use-case already exists. > I can think of some light compartmentalisation where we have a pkey > that's "privileged" and all threads have a POR_EL0 that prevents access > to that pkey. The signal handler would have more permissive rights to > that privileged pkey. I'd not proactively add support for this though. I'd not proactively diverge from other architectures, either :p Will
