linux-kernel - Re: [RFC] Restore PKRU to user-defined value after signal handling

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 for Android: free password hash cracker in your pocket

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

Message-ID:
 <SJ0PR10MB4720CAFB829ABC467384BC799C5D2@SJ0PR10MB4720.namprd10.prod.outlook.com>
Date: Fri, 8 Nov 2024 09:58:05 +0000
From: Rudi Horn <rudi.horn@...cle.com>
To: Dave Hansen <dave.hansen@...el.com>,
        Aruna Ramakrishna
	<aruna.ramakrishna@...cle.com>
CC: Thomas Gleixner <tglx@...utronix.de>,
        "mingo@...hat.com"
	<mingo@...hat.com>,
        "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Joe Jin
	<joe.jin@...cle.com>, Jeff Xu <jeffxu@...omium.org>
Subject: Re: [RFC] Restore PKRU to user-defined value after signal handling

> Tell me more, please.  What changes to the XSAVE area are you concerned
> about?  There is currently vanishingly little code between the XSAVE and
> overwriting the PKRU state.

I'm concerned about any inconsistency between the XSAVE area and the
current CPU buffer, which can be caused both by changing the CPU state 
(e.g. a zeroall instruction, or any FP register usage) as well as by changing the 
XSAVE area (we do not know what future CPU features to expect). There is
currently nothing happening between these code sequences, so I'm not
concerned about this change being incorrect. I do think it would be easier to
read / understand and harder to accidentally break the code going forward if
the XSAVE code was immediately followed by the xgetbv instruction.

> The question still stands as to whether the new XSTATE_BV value should
> be calculated by the kernel or read directly from the userspace buffer.

I don't really mind either way. It somewhat depends on what the overhead of
reading the value from the userspace buffer is. It is a bit unfortunate there
isn't (that I know of) a read-modify-write sequence on user space memory that
has similar overhead to a plain user write. I think it would be safe to opt out of
the userspace xfeatures write if the PKRU bit was set in XGETBV(1).

> I think it's safe to assume that if you use XGETBV(1) that the state is
> sticky at least until there's an explicit change to a state component.

I agree with this, we already rely on the xstate (a superset of XGETBV(1))
being sticky until we save it.

Thanks,
Rudi