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

From: Aruna Ramakrishna
Date: Fri Mar 22 2024 - 14:31:21 EST




> 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