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

[Aruna Ramakrishna]

> On Mar 22, 2024, at 2:46 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
> 
> Ok, this looks a lot saner than the first patch.
> 
> A couple of requests:
> 
> 1)
> 
> Please split out all the PKRU parameter passing interface changes into a 
> separate patch. Ie. split out patches that don't change any behavior, and 
> try to make the final feature-enabling (bug-fixing) patch as small and easy 
> to read as possible. Maybe even have 3 patches:
> 
>  - function interface changes
>  - helper function additions
>  - behavioral changes to signal handler pkru context
> 
> 2)
> 
> I do agree that isolation of sandboxed execution into a non-zero pkey might 
> make sense. But this really needs an actual testcase.
> 
> 3)
> 
> The semantics you've implemented for sigaltstacks are not the only possible 
> ones. In principle, a signal handler with its own stack might want to have 
> its own key(s) enabled. In a way a Linux signal handler is a mini-thread 
> created on the fly, with its own stack and its own attributes. Some thought 
> & analysis should go into which way to go here, and the best path should be 
> chosen. Fixing the SIGSEGV you observed should be a happy side effect of 
> other worthwile improvements.
> 
> Thanks,
> 
> Ingo

Thank you, Ingo!

I will split this patch into multiple patches when I send it out as a patch review
request next. And add a testcase.

I agree that this patch covers a very specific use case, and it probably raises
more questions than it answers. That’s why I sent it out as an RFC - because
I wasn’t sure if this was the best way to add this functionality, and I wanted the
experts to weigh in.

As Dave suggested, I can instead do wrpkru(0) to enable all pkeys before
XSAVE.

Thanks,
Aruna