linux-kernel - Re: [RFC PATCH v2 1/1] 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20240425215846.3276082-1-jeffxu@chromium.org>
Date: Thu, 25 Apr 2024 21:58:46 +0000
From: jeffxu@...omium.org
To: aruna.ramakrishna@...cle.com
Cc: andrew.brownsword@...cle.com,
	dave.hansen@...ux.intel.com,
	linux-kernel@...r.kernel.org,
	matthias.neugschwandtner@...cle.com,
	tglx@...utronix.de,
	jeffxu@...omium.org,
	jeffxu@...gle.com,
	jannh@...gle.com,
	sroettger@...gle.com,
	x86@...nel.org
Subject: Re: [RFC PATCH v2 1/1] x86/pkeys: update PKRU to enable pkey 0 before XSAVE

From: Jeff Xu <jeffxu@...omium.org>

>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.
>
This is exactly right. we wants to use altstack with its own pkey. The pkey
won't be writeable during thread's normal operation, only by signaling
handling itself.

Thanks
-Jeff

>Thanks,
>
>	Ingo
>