All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Sneddon <daniel.sneddon@linux.intel.com>
To: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, hpa@zytor.com, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, pawan.kumar.gupta@linux.intel.com
Subject: Re: [PATCH 6/6] x86/bugs: Clean-up verw mitigations
Date: Tue, 8 Oct 2024 09:17:44 -0700	[thread overview]
Message-ID: <b6d33fd0-cdee-4cfa-819f-3ad2b54867d6@linux.intel.com> (raw)
In-Reply-To: <20241007193726.m5mzkjjy4yscge6x@treble>

On 10/7/24 12:37, Josh Poimboeuf wrote:
> On Tue, Sep 24, 2024 at 03:31:40PM -0700, Daniel Sneddon wrote:
>> +static void __init md_clear_select_mitigation(void)
>> +{
>>  	/*
>> -	 * X86_FEATURE_CLEAR_CPU_BUF is now enabled. Update MDS, TAA and MMIO
>> -	 * Stale Data mitigation, if necessary.
>> +	 * If no CPU bug needs VERW, all VERW mitigations are disabled, or all
>> +	 * mitigations are disabled we bail.
>>  	 */
> 
> It's already clear what the code is doing, no comment necessary.
> 
Will remove.
>> -	if (mds_mitigation == MDS_MITIGATION_OFF &&
>> -	    boot_cpu_has_bug(X86_BUG_MDS)) {
>> +	if (!cpu_bug_needs_verw() || verw_mitigations_disabled() ||
>> +	    cpu_mitigations_off()) {
>> +		mds_mitigation = MDS_MITIGATION_OFF;
>> +		taa_mitigation = TAA_MITIGATION_OFF;
>> +		mmio_mitigation = MMIO_MITIGATION_OFF;
>> +		rfds_mitigation = RFDS_MITIGATION_OFF;
>> +		goto out;
>> +	}
> 
> In the case of verw_mitigations_disabled() it's weird to write the
> variables again if they're already OFF.  That should be a separate
> check.
> 
Sure. I will separate them out.
>> +
>> +	/* Check that at least one mitigation is using the verw mitigaiton.
>> +	 * If the cpu doesn't have the correct ucode or if the BUG_* is mitigated
>> +	 * by disabling a feature we won't want to use verw. Ignore MMIO
>> +	 * for now since it depends on what the others choose.
>> +	 */
> 
> Again I think this comment isn't needed as the code is pretty
> straightforward.  The only surprise is the MMIO dependency on
> X86_FEATURE_CLEAR_CPU_BUF, but that's called out below.
> 
Will remove.
>> +
>> +	if (boot_cpu_has_bug(X86_BUG_MDS)) {
>>  		mds_mitigation = MDS_MITIGATION_FULL;
>>  		mds_select_mitigation();
>> +	}  else {
>> +		mds_mitigation = MDS_MITIGATION_OFF;
>>  	}
>> -	if (taa_mitigation == TAA_MITIGATION_OFF &&
>> -	    boot_cpu_has_bug(X86_BUG_TAA)) {
>> +	if (boot_cpu_has_bug(X86_BUG_TAA)) {
>>  		taa_mitigation = TAA_MITIGATION_VERW;
>>  		taa_select_mitigation();
>> +	} else {
>> +		taa_mitigation = TAA_MITIGATION_OFF;
>>  	}
>> -	/*
>> -	 * MMIO_MITIGATION_OFF is not checked here so that mmio_stale_data_clear
>> -	 * gets updated correctly as per X86_FEATURE_CLEAR_CPU_BUF state.
>> -	 */
>> +	if (boot_cpu_has_bug(X86_BUG_RFDS)) {
>> +		rfds_mitigation = RFDS_MITIGATION_VERW;
>> +		rfds_select_mitigation();
>> +	} else {
>> +		rfds_mitigation = RFDS_MITIGATION_OFF;
>> +	}
> 
> This spaghetti can be simplifed by relying on *_select_mitigation() to
> set the mitigation, for example:
> 
> static void __init mds_select_mitigation(void)
> {
> 	if (!boot_cpu_has_bug(X86_BUG_MDS))
> 		mds_mitigation = MDS_MITIGATION_OFF;
> 	else if (boot_cpu_has(X86_FEATURE_MD_CLEAR))
> 		mds_mitigation = MDS_MITIGATION_VERW;
> 	else
> 		mds_mitigation = MDS_MITIGATION_VMWERV;
> }
> 
> Then you can just do:
> 
> 	mds_select_mitigation();
> 	taa_select_mitigation();
> 	rfds_select_mitigation();
> 
> 
You're right. That is much cleaner. Will fix.
>> +	if (mds_mitigation == MDS_MITIGATION_FULL ||
>> +	    taa_mitigation == TAA_MITIGATION_VERW ||
>> +	    rfds_mitigation == RFDS_MITIGATION_VERW)
> 
> For consistency can we rename MDS_MITIGATION_FULL to
> MDS_MITIGATION_VERW?
> 
Will do!
>> +		setup_force_cpu_cap(X86_FEATURE_CLEAR_CPU_BUF);
>> +
>> +	/* Now handle MMIO since it may not use X86_FEATURE_CLEAR_CPU_BUF */
> 
> I would clarify this a bit, something like:
> 
> 	/*
> 	 * The MMIO mitigation has a dependency on
> 	 * X86_FEATURE_CLEAR_CPU_BUF so this must be called after it
> 	 * gets set.
> 	 */
> 
Will update.
>>  	if (boot_cpu_has_bug(X86_BUG_MMIO_STALE_DATA)) {
>>  		mmio_mitigation = MMIO_MITIGATION_VERW;
>>  		mmio_select_mitigation();
>> +	} else {
>> +		mmio_mitigation = MMIO_MITIGATION_OFF;
>>  	}
>> -	if (rfds_mitigation == RFDS_MITIGATION_OFF &&
>> -	    boot_cpu_has_bug(X86_BUG_RFDS)) {
>> -		rfds_mitigation = RFDS_MITIGATION_VERW;
>> -		rfds_select_mitigation();
>> -	}
>> +
>> +	/* handle nosmt */
> 
> Again I think this comment is superfluous.
> 
Will remove.
>> +	if (!boot_cpu_has(X86_BUG_MSBDS_ONLY) &&
>> +	    (mds_nosmt || cpu_mitigations_auto_nosmt()))
>> +		cpu_smt_disable(false);
>> +
>> +	if (taa_nosmt || mmio_nosmt || cpu_mitigations_auto_nosmt())
>> +		cpu_smt_disable(false);
>> +
> 

Thanks for the review!


      reply	other threads:[~2024-10-08 16:17 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-24 22:31 [PATCH 0/6] VERW based clean-up Daniel Sneddon
2024-09-24 22:31 ` [PATCH 1/6] x86/bugs: Create single parameter for VERW based mitigations Daniel Sneddon
2024-10-08 19:24   ` Kaplan, David
2024-10-09 16:17     ` Daniel Sneddon
2024-10-09 16:36       ` Kaplan, David
2024-10-09 16:39         ` Daniel Sneddon
2024-10-09 19:44           ` Daniel Sneddon
2024-10-09 20:02             ` Kaplan, David
2024-10-09 20:34               ` Daniel Sneddon
2024-10-10  4:52     ` Josh Poimboeuf
2024-10-10 14:57       ` Borislav Petkov
2024-10-14 15:42         ` Daniel Sneddon
2024-10-15 13:52           ` Borislav Petkov
2024-10-15 14:05             ` Daniel Sneddon
2024-09-24 22:31 ` [PATCH 2/6] x86/bugs: Remove MDS command line Daniel Sneddon
2024-09-24 22:34   ` Dave Hansen
2024-09-24 22:41     ` Daniel Sneddon
2024-09-24 22:31 ` [PATCH 3/6] x86/bugs: Remove TAA kernel parameter Daniel Sneddon
2024-09-24 22:31 ` [PATCH 4/6] x86/bugs: Remove MMIO " Daniel Sneddon
2024-09-24 22:31 ` [PATCH 5/6] x86/bugs: Remove RFDS " Daniel Sneddon
2024-09-24 22:31 ` [PATCH 6/6] x86/bugs: Clean-up verw mitigations Daniel Sneddon
2024-10-02 14:20   ` Nikolay Borisov
2024-10-02 14:46     ` Daniel Sneddon
2024-10-02 14:54       ` Nikolay Borisov
2024-10-07 19:37   ` Josh Poimboeuf
2024-10-08 16:17     ` Daniel Sneddon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b6d33fd0-cdee-4cfa-819f-3ad2b54867d6@linux.intel.com \
    --to=daniel.sneddon@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.