Re: PKU usage improvements for threads

[Dave Hansen]

On 8/22/22 13:40, Kees Cook wrote:
> 1) It appears to be a bug that a thread without the correct PK can make
> VMAs covered by a separate PK, out from under other threads. (e.g. mmap
> a new mapping to wipe out the defined PK for it.) It seems that PK checks
> should be made when modifying VMAs.

Hi Kees,

Could you give an example of this?  Is this something along the lines of
a mmap(MAP_FIXED) wiping out an earlier mapping?  Or, is it more subtle
than that?

I'm not sure I know of any bugs in the area.

> 2) It would be very helpful to have a mechanism for the signal stack to
> be PK aware, in the sense that the kernel would switch to a predefined
> PK. i.e. having a new interface to sigaltstack() which includes a PK.

Are you thinking that when switching to the sigaltstack that it would
also pick up a specific PKRU value?  Or, that it would ensure that PKRU
allows access to the sigaltstack's pkey?  Logically something like this:

	stack_t sas = {
		ss_sp = stack_ptr;
		ss_flags = ... flags;
		ss_size = ...;
		ss_pkey = 12;
	};

Then the kernel would set up RSP to point to ss_sp, and do (logically):

   pkkru &= ~(3<<(12*2)); // clear Write and Access-disable for pkey-12

before building the signal frame running the signal handler?

> Are either of these something the PKU authors have considered? (Or are
> there some details we're missing in this area?)

We've talked about having signal behavior which might give different
PKRU values at signal entry, but nothing too concrete.  Something like
that wouldn't be *awful* to implement.  It would also be nice that it
would be confined to folks that set up special signal handlers anyway
and that context is already pretty special.

I'd love to hear more why this behavior is useful and how it will be used.