[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b5093703-1c86-4706-9e54-b6d2d413c417@suse.com>
Date: Wed, 2 Oct 2024 17:54:14 +0300
From: Nikolay Borisov <nik.borisov@...e.com>
To: Daniel Sneddon <daniel.sneddon@...ux.intel.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 2.10.24 г. 17:46 ч., Daniel Sneddon wrote:
> 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.
Ah, indeed.
Reviewed-by: Nikolay Borisov <nik.borisov@...e.com>
Powered by blists - more mailing lists