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

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]

Message-ID: <67F8113C-8E0F-4560-8967-FFF9ABF4FBEF@oracle.com>
Date: Fri, 15 Mar 2024 04:47:47 +0000
From: Aruna Ramakrishna <aruna.ramakrishna@...cle.com>
To: Dave Hansen <dave.hansen@...el.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        Matthias Neugschwandtner <matthias.neugschwandtner@...cle.com>,
        Eric Sedlar
	<eric.sedlar@...cle.com>,
        Andrew Brownsword <andrew.brownsword@...cle.com>,
        Craig Schelp <craig.schelp@...cle.com>
Subject: Re: [RFC PATCH] x86/pkeys: update PKRU to enable pkey 0 before XSAVE


> On Mar 14, 2024, at 11:30 AM, Dave Hansen <dave.hansen@...el.com> 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