Re: [RFC PATCH] x86/pkeys: update PKRU to enable pkey 0 before XSAVE

[Aruna Ramakrishna]

> On Mar 14, 2024, at 11:30 AM, Dave Hansen <dave.hansen@xxxxxxxxx> wrote:
> 
> On 3/14/24 11:14, Aruna Ramakrishna wrote:
>> I thought the PKRU value being reset in the signal handler was supposed 
>> to be the default behavior. In which case, this is a bug.
>> 
>> "Signal Handler Behavior
>> Each time a signal handler is invoked (including nested signals),
>> the thread is temporarily given a new, default set of protection
>> key rights that override the rights from the interrupted context.”
>> 
>> (Ref: https://man7.org/linux/man-pages/man7/pkeys.7.html)
> 
> As the person who wrote those words, I can honestly say that there were
> *ZERO* considerations for what the kernel's permissions were while
> setting up the frame.  I was assuming then and assume to this day that
> it's practically impossible to turn off pkey-0 writes and get sane behavior.
> 
> If we want to lawyer-word the manpage, I'll just argue that "Each time a
> signal handler is invoked" literally doesn't apply until the moment that
> RIP is pointing back to userspace. :)
> 
> If this is truly about the manpage, then I'll happily amend the manpage
> to say, "don't turn off pkey 0 access or else".  I'd *MUCH* rather do
> that than add more pkey munging to the kernel.
> 

It’s not about the man page - it's just that, my understanding of this flow and this use case stems from there. I think we assumed that we can turn off pkey 0 and still be able to set up the alt sig stack (and have the kernel reset it to init_pkru anyway) - and when that didn’t work, it seemed like a bug. :) 

> In other words, you're not going to spur me into action my thwapping me
> with the manpage that I wrote.  You've got to convince me that your new
> use case is valid, this is the best way to support your new use case,
> and that your implementation of the new feature is sane.
> 
> 

Matthias/Eric,
Can you please talk about the use case in greater detail?

Thanks,
Aruna