[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fdda8f74-4d9a-4aff-ad5b-c7a1f2b0ab0b@linux.intel.com>
Date: Wed, 2 Oct 2024 07:46:49 -0700
From: Daniel Sneddon <daniel.sneddon@...ux.intel.com>
To: Nikolay Borisov <nik.borisov@...e.com>, Jonathan Corbet <corbet@....net>,
Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>,
Peter Zijlstra <peterz@...radead.org>, Josh Poimboeuf <jpoimboe@...nel.org>,
Ingo Molnar <mingo@...hat.com>, Dave Hansen <dave.hansen@...ux.intel.com>,
x86@...nel.org
Cc: hpa@...or.com, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
pawan.kumar.gupta@...ux.intel.com
Subject: Re: [PATCH 6/6] x86/bugs: Clean-up verw mitigations
On 10/2/24 07:20, Nikolay Borisov wrote:
>> + if (boot_cpu_has_bug(X86_BUG_MDS)) {
>> mds_mitigation = MDS_MITIGATION_FULL;
>> mds_select_mitigation();
>> + } else {
>> + mds_mitigation = MDS_MITIGATION_OFF;
>> }
>
> BUt with this logic if CONFIG_MITIGATION_MDS is deselected meaning
> mds_mitigations will have the value MDS_MITIGATION_OFF, yet now you will
> set it to _FULL thereby overriding the compile-time value of the user.
> So shouldn't this condition be augmented to alsoo consider
> CONFIG_MITIGATION_MDS compile time value?
CONFIG_MITIGATION_MDS is used to set the value of the mds_mitigation variable.
Same goes for all the other mitigations touched here. Those variables are
checked in verw_mitigations_disabled() which is called just before this code. If
all of them are configured off, we return without enabling any of the mitigations.
Powered by blists - more mailing lists