[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3611ea4d-d714-4ef2-9dd5-d1637e806411@intel.com>
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
Powered by blists - more mailing lists