mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: David Kaplan <david.kaplan@amd.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org,
	Brendan Jackman <jackmanb@google.com>,
	Derek Manwaring <derekmn@amazon.com>
Subject: Re: [PATCH v4 03/36] x86/bugs: Restructure mmio mitigation
Date: Thu, 13 Mar 2025 12:26:06 -0700	[thread overview]
Message-ID: <20250313192606.iijythngqtpx4tyy@desk> (raw)
In-Reply-To: <20250313093617.GHZ9KnEXpdM4dwLYFz@fat_crate.local>

On Thu, Mar 13, 2025 at 10:36:17AM +0100, Borislav Petkov wrote:
> I'd expect to see:
> 
> 	if (mmio_mitigation == MMIO_MITIGATION_AUTO) {
>                 mmio_mitigation = MMIO_MITIGATION_VERW;
> 		verw_mitigation_selected = true;
> 	}
> 
>         if (boot_cpu_has_bug(X86_BUG_MDS) || taa_vulnerable())
>                 verw_mitigation_selected = true;
> 
> because the above branch already selected MMIO_MITIGATION_VERW so we might as
> well set verw_mitigation_selected, right?

There is a subtle difference between setting verw_mitigation_selected and
MMIO_MITIGATION_VERW. The former is a system-wide switch that indicates
VERW is needed at both kernel-exit and VMenter. MMIO Stale Data is
different from other VERW based mitigations because it only requires VERW
at VMenter, when not affected by MDS/TAA. So, turning the system-wide knob
here would be wrong.

> > +static void __init mmio_update_mitigation(void)
> > +{
> > +	if (!boot_cpu_has_bug(X86_BUG_MMIO_STALE_DATA) || cpu_mitigations_off())
> > +		return;
> > +
> > +	if (verw_mitigation_selected)
> > +		mmio_mitigation = MMIO_MITIGATION_VERW;
[...]
> > +	if (boot_cpu_has_bug(X86_BUG_MMIO_UNKNOWN))
> 
> Btw, that UNKNOWN thing is just silly. Looking at git history:
> 
> 7df548840c49 ("x86/bugs: Add "unknown" reporting for MMIO Stale Data")
> 
> this was added just so that it doesn't say "Not affected" about those CPUs but
> "unknown."
> 
> But
> 
>   "Mitigation is not deployed when the status is unknown."
> 
> so if it is only about reporting, I think we can synthesize the logic of this:
> 
>         if (!arch_cap_mmio_immune(x86_arch_cap_msr)) {
>                 if (cpu_matches(cpu_vuln_blacklist, MMIO))
>                         setup_force_cpu_bug(X86_BUG_MMIO_STALE_DATA);
>                 else if (!cpu_matches(cpu_vuln_whitelist, NO_MMIO))
>                         setup_force_cpu_bug(X86_BUG_MMIO_UNKNOWN);
>         }
> 
> into a separate function and get rid of that X86_BUG_MMIO_UNKNOWN thing.

Hmm, that would not be straightforward, specially for sysfs status. The
above logic requires parsing the cpu_vuln_whitelist which is not available
after init. Moreover, sysfs reads would become slower if it has to read an
MSR and parse tables.

Also, cpu_show_common() by default shows "Not affected" in the absence of
bug bit. So setting X86_BUG_MMIO_UNKNOWN is simpler overall.

cpu_show_common(bug)
{
	if (!boot_cpu_has_bug(bug))
		return sysfs_emit(buf, "Not affected\n");

  parent reply	other threads:[~2025-03-13 19:26 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-10 16:39 [PATCH v4 00/36] Attack vector controls David Kaplan
2025-03-10 16:39 ` [PATCH v4 01/36] x86/bugs: Restructure mds mitigation David Kaplan
2025-03-10 16:39 ` [PATCH v4 02/36] x86/bugs: Restructure taa mitigation David Kaplan
2025-03-10 16:39 ` [PATCH v4 03/36] x86/bugs: Restructure mmio mitigation David Kaplan
2025-03-13  9:36   ` Borislav Petkov
2025-03-13 14:19     ` Kaplan, David
2025-03-13 19:26     ` Pawan Gupta [this message]
2025-03-18 14:16       ` MMIO and VERW Borislav Petkov
2025-03-18 16:25         ` Pawan Gupta
2025-03-18 16:34           ` Borislav Petkov
2025-03-18 16:56             ` Pawan Gupta
2025-03-18 17:37               ` Borislav Petkov
2025-03-18 18:15                 ` Pawan Gupta
2025-03-18 18:55                   ` Borislav Petkov
2025-03-24  9:29       ` [PATCH v4 03/36] x86/bugs: Restructure mmio mitigation Borislav Petkov
2025-03-24 17:41         ` Pawan Gupta
2025-03-25 11:31           ` Borislav Petkov
2025-03-10 16:39 ` [PATCH v4 04/36] x86/bugs: Restructure rfds mitigation David Kaplan
2025-04-10 16:24   ` Josh Poimboeuf
2025-04-14 19:10     ` Kaplan, David
2025-03-10 16:39 ` [PATCH v4 05/36] x86/bugs: Remove md_clear_*_mitigation() David Kaplan
2025-03-10 16:39 ` [PATCH v4 06/36] x86/bugs: Restructure srbds mitigation David Kaplan
2025-03-10 16:39 ` [PATCH v4 07/36] x86/bugs: Restructure gds mitigation David Kaplan
2025-03-10 16:39 ` [PATCH v4 08/36] x86/bugs: Restructure spectre_v1 mitigation David Kaplan
2025-03-10 16:39 ` [PATCH v4 09/36] x86/bugs: Only allow retbleed=stuff on Intel David Kaplan
2025-03-10 16:39 ` [PATCH v4 10/36] x86/bugs: Restructure retbleed mitigation David Kaplan
2025-03-10 16:39 ` [PATCH v4 11/36] x86/bugs: Restructure spectre_v2_user mitigation David Kaplan
2025-03-12  9:49   ` kernel test robot
2025-04-10 16:26   ` Josh Poimboeuf
2025-04-14 19:20     ` Kaplan, David
2025-04-10 16:41   ` Josh Poimboeuf
2025-04-14 19:20     ` Kaplan, David
2025-04-14 23:48       ` Josh Poimboeuf
2025-04-15 14:56         ` Kaplan, David
2025-03-10 16:39 ` [PATCH v4 12/36] x86/bugs: Restructure bhi mitigation David Kaplan
2025-03-10 16:40 ` [PATCH v4 13/36] x86/bugs: Restructure spectre_v2 mitigation David Kaplan
2025-04-10 17:08   ` Josh Poimboeuf
2025-04-14 19:25     ` Kaplan, David
2025-03-10 16:40 ` [PATCH v4 14/36] x86/bugs: Restructure ssb mitigation David Kaplan
2025-03-10 16:40 ` [PATCH v4 15/36] x86/bugs: Restructure l1tf mitigation David Kaplan
2025-03-10 16:40 ` [PATCH v4 16/36] x86/bugs: Restructure srso mitigation David Kaplan
2025-04-10 17:38   ` Josh Poimboeuf
2025-04-14 21:12     ` Kaplan, David
2025-03-10 16:40 ` [PATCH v4 17/36] Documentation/x86: Document the new attack vector controls David Kaplan
2025-04-10 18:14   ` Josh Poimboeuf
2025-04-14 21:15     ` Kaplan, David
2025-04-14 23:51       ` Josh Poimboeuf
2025-04-15 14:59         ` Kaplan, David
2025-04-15 15:32           ` Josh Poimboeuf
2025-04-15 16:10             ` Kaplan, David
2025-04-15 16:47               ` Josh Poimboeuf
2025-04-15 17:06                 ` Kaplan, David
2025-03-10 16:40 ` [PATCH v4 18/36] cpu: Define attack vectors David Kaplan
2025-04-10 18:12   ` Josh Poimboeuf
2025-04-14 21:20     ` Kaplan, David
2025-03-10 16:40 ` [PATCH v4 19/36] x86/Kconfig: Arch attack vector support David Kaplan
2025-03-10 16:40 ` [PATCH v4 20/36] x86/bugs: Determine relevant vulnerabilities based on attack vector controls David Kaplan
2025-03-12 11:32   ` kernel test robot
2025-03-10 16:40 ` [PATCH v4 21/36] x86/bugs: Add attack vector controls for mds David Kaplan
2025-03-10 16:40 ` [PATCH v4 22/36] x86/bugs: Add attack vector controls for taa David Kaplan
2025-03-10 16:40 ` [PATCH v4 23/36] x86/bugs: Add attack vector controls for mmio David Kaplan
2025-03-10 16:40 ` [PATCH v4 24/36] x86/bugs: Add attack vector controls for rfds David Kaplan
2025-03-10 16:40 ` [PATCH v4 25/36] x86/bugs: Add attack vector controls for srbds David Kaplan
2025-03-10 16:40 ` [PATCH v4 26/36] x86/bugs: Add attack vector controls for gds David Kaplan
2025-03-10 16:40 ` [PATCH v4 27/36] x86/bugs: Add attack vector controls for spectre_v1 David Kaplan
2025-03-10 16:40 ` [PATCH v4 28/36] x86/bugs: Add attack vector controls for retbleed David Kaplan
2025-03-10 16:40 ` [PATCH v4 29/36] x86/bugs: Add attack vector controls for spectre_v2_user David Kaplan
2025-03-10 16:40 ` [PATCH v4 30/36] x86/bugs: Add attack vector controls for bhi David Kaplan
2025-03-10 16:40 ` [PATCH v4 31/36] x86/bugs: Add attack vector controls for spectre_v2 David Kaplan
2025-03-10 16:40 ` [PATCH v4 32/36] x86/bugs: Add attack vector controls for l1tf David Kaplan
2025-03-10 16:40 ` [PATCH v4 33/36] x86/bugs: Add attack vector controls for srso David Kaplan
2025-03-10 16:40 ` [PATCH v4 34/36] x86/pti: Add attack vector controls for pti David Kaplan
2025-03-10 16:40 ` [PATCH v4 35/36] x86/bugs: Print enabled attack vectors David Kaplan
2025-03-10 16:40 ` [PATCH v4 36/36] cpu: Show attack vectors in sysfs David Kaplan
2025-03-10 18:45 ` [PATCH v4 00/36] Attack vector controls Ingo Molnar
2025-03-10 20:46   ` Kaplan, David

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=20250313192606.iijythngqtpx4tyy@desk \
    --to=pawan.kumar.gupta@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=david.kaplan@amd.com \
    --cc=derekmn@amazon.com \
    --cc=hpa@zytor.com \
    --cc=jackmanb@google.com \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®