linux-kernel - Re: PKU usage improvements for threads

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 22 Aug 2022 14:11:07 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Kees Cook <keescook@...omium.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Cc:     Stephen Röttger <sroettger@...gle.com>,
        x86@...nel.org, linux-kernel@...r.kernel.org,
        Andy Lutomirski <luto@...nel.org>
Subject: Re: PKU usage improvements for threads

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.