linux-kernel - Re: [PATCH 15/14] x86/gds: Lock GDS mitigation when keylocker feature is present

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 Apr 2024 15:13:06 -0700
From: "Chang S. Bae" <chang.seok.bae@...el.com>
To: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
CC: <linux-kernel@...r.kernel.org>, <x86@...nel.org>,
	<dan.j.williams@...el.com>, <bernie.keany@...el.com>,
	<charishma1.gairuboyina@...el.com>, Josh Poimboeuf <jpoimboe@...nel.org>,
	<daniel.sneddon@...ux.intel.com>, <antonio.gomez.iglesias@...ux.intel.com>
Subject: Re: [PATCH 15/14] x86/gds: Lock GDS mitigation when keylocker feature
 is present

On 4/22/2024 2:32 PM, Pawan Gupta wrote:
> 
> To enable Key Locker feature, "proper mitigation" is microcode mitigation
> enabled and the GDS_MITG_LOCK bit set in MSR_IA32_MCU_OPT_CTRL. Do you
> agree?
> > If not via this patch, how is GDS_MITG_LOCK going to be set?

The lock bit seems to be set by microcode when SGX is available. 
However, if the lock bit is not set for Key Locker, it does seem odd. 
Introducing kernel code to override this situation might be seen as a 
workaround rather than a proper solution, potentially leading to more 
confusion.

I'd rather investigate the behavior of the microcode further, verify its 
consistency, and gain a clearer understanding of the requirement for 
this lock bit.

Thanks,
Chang