All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, tony.luck@intel.com,
	antonio.gomez.iglesias@linux.intel.com,
	Daniel Sneddon <daniel.sneddon@linux.intel.com>,
	andrew.cooper3@citrix.com, Josh Poimboeuf <jpoimboe@kernel.org>
Subject: Re: [RESEND RFC PATCH] x86/bugs: Add "unknown" reporting for MMIO Stale Data
Date: Thu, 28 Jul 2022 14:00:13 +0200	[thread overview]
Message-ID: <YuJ6TQpSTIeXLNfB@zn.tnic> (raw)
In-Reply-To: <a932c154772f2121794a5f2eded1a11013114711.1657846269.git.pawan.kumar.gupta@linux.intel.com>

On Thu, Jul 14, 2022 at 06:30:18PM -0700, Pawan Gupta wrote:
> Older CPUs beyond its Servicing period are not listed in the affected
> processor list for MMIO Stale Data vulnerabilities. These CPUs currently
> report "Not affected" in sysfs, which may not be correct.
> 
> Add support for "Unknown" reporting for such CPUs. Mitigation is not
> deployed when the status is "Unknown".
> 
> "CPU is beyond its Servicing period" means these CPUs are beyond their
> Servicing [1] period and have reached End of Servicing Updates (ESU) [2].
> 
>   [1] Servicing: The process of providing functional and security
>   updates to Intel processors or platforms, utilizing the Intel Platform
>   Update (IPU) process or other similar mechanisms.
> 
>   [2] End of Servicing Updates (ESU): ESU is the date at which Intel
>   will no longer provide Servicing, such as through IPU or other similar
>   update processes. ESU dates will typically be aligned to end of
>   quarter.

The explanations of those things need to be...

> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Suggested-by: Tony Luck <tony.luck@intel.com>
> Fixes: 8d50cdf8b834 ("x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data")
> Cc: stable@vger.kernel.org
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> ---
> CPU vulnerability is unknown if, hardware doesn't set the immunity bits
> and CPU is not in the known-affected-list.
> 
> In order to report the unknown status, this patch sets the MMIO bug
> for all Intel CPUs that don't have the hardware immunity bits set.
> Based on the known-affected-list of CPUs, mitigation selection then
> deploys the mitigation or sets the "Unknown" status; which is ugly.
> 
> I will appreciate suggestions to improve this.
> 
> Thanks,
> Pawan
> 
>  .../hw-vuln/processor_mmio_stale_data.rst     |  3 +++
>  arch/x86/kernel/cpu/bugs.c                    | 11 +++++++-
>  arch/x86/kernel/cpu/common.c                  | 26 +++++++++++++------
>  arch/x86/kernel/cpu/cpu.h                     |  1 +
>  4 files changed, 32 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst b/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst
> index 9393c50b5afc..55524e0798da 100644
> --- a/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst
> +++ b/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst
> @@ -230,6 +230,9 @@ The possible values in this file are:
>       * - 'Mitigation: Clear CPU buffers'
>         - The processor is vulnerable and the CPU buffer clearing mitigation is
>           enabled.
> +     * - 'Unknown: CPU is beyond its Servicing period'
> +       - The processor vulnerability status is unknown because it is
> +	 out of Servicing period. Mitigation is not attempted.

... here.

> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 736262a76a12..82088410870e 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -1286,6 +1286,22 @@ static bool arch_cap_mmio_immune(u64 ia32_cap)
>  		ia32_cap & ARCH_CAP_SBDR_SSDP_NO);
>  }
>  
> +bool __init mmio_stale_data_unknown(void)

This function need to go to ...cpu/intel.c

> +{
> +	u64 ia32_cap = x86_read_arch_cap_msr();
> +
> +	if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
> +		return false;

<---- newline here.

> +	/*
> +	 * CPU vulnerability is unknown when, hardware doesn't set the

no comma after the "when"

> +	 * immunity bits and CPU is not in the known affected list.
> +	 */
> +	if (!cpu_matches(cpu_vuln_blacklist, MMIO) &&
> +	    !arch_cap_mmio_immune(ia32_cap))
> +		return true;

<---- newline here.

> +	return false;
> +}
> +
>  static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
>  {
>  	u64 ia32_cap = x86_read_arch_cap_msr();
> @@ -1349,14 +1365,8 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
>  	    cpu_matches(cpu_vuln_blacklist, SRBDS | MMIO_SBDS))
>  		    setup_force_cpu_bug(X86_BUG_SRBDS);
>  
> -	/*
> -	 * Processor MMIO Stale Data bug enumeration
> -	 *
> -	 * Affected CPU list is generally enough to enumerate the vulnerability,
> -	 * but for virtualization case check for ARCH_CAP MSR bits also, VMM may
> -	 * not want the guest to enumerate the bug.
> -	 */
> -	if (cpu_matches(cpu_vuln_blacklist, MMIO) &&
> +	 /* Processor MMIO Stale Data bug enumeration */
> +	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&

Why is that vendor check here? We have the cpu_vuln_blacklist for a
reason.

>  	    !arch_cap_mmio_immune(ia32_cap))
>  		setup_force_cpu_bug(X86_BUG_MMIO_STALE_DATA);

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

  parent reply	other threads:[~2022-07-28 12:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-15  1:30 [RESEND RFC PATCH] x86/bugs: Add "unknown" reporting for MMIO Stale Data Pawan Gupta
2022-07-28  1:29 ` Pawan Gupta
2022-07-28 12:00 ` Borislav Petkov [this message]
2022-07-29  2:28   ` Pawan Gupta
2022-07-29 10:40     ` David Laight
2022-07-29 17:45       ` 'Pawan Gupta'
2022-07-29 14:05     ` Borislav Petkov
2022-07-29 17:36       ` Pawan Gupta
2022-07-29 20:30         ` Borislav Petkov
2022-07-29 21:46           ` Pawan Gupta
2022-07-29 22:02             ` Borislav Petkov
2022-07-30  2:31               ` Pawan Gupta
2022-07-29 22:54             ` Dave Hansen
2022-07-29 23:07               ` Tony Luck
2022-07-29 23:18                 ` Dave Hansen
2022-07-30  2:40                 ` Pawan Gupta
2022-07-28 19:08 ` Dave Hansen
2022-07-29 17:59   ` Pawan Gupta
2022-07-29 18:02     ` Dave Hansen

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=YuJ6TQpSTIeXLNfB@zn.tnic \
    --to=bp@alien8.de \
    --cc=andrew.cooper3@citrix.com \
    --cc=antonio.gomez.iglesias@linux.intel.com \
    --cc=corbet@lwn.net \
    --cc=daniel.sneddon@linux.intel.com \
    --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=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --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.