All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: speck@linutronix.de
Subject: [MODERATED] Re: [patch V6 04/14] MDS basics 4
Date: Sat, 2 Mar 2019 02:28:55 +0100	[thread overview]
Message-ID: <20190302012854.GD22355@lenoir> (raw)
In-Reply-To: <20190301214847.524432729@linutronix.de>

On Fri, Mar 01, 2019 at 10:47:42PM +0100, speck for Thomas Gleixner wrote:
> Subject: [patch V6 04/14] x86/speculation/mds: Add BUG_MSBDS_ONLY
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> This bug bit is set on CPUs which are only affected by Microarchitectural
> Store Buffer Data Sampling (MSBDS) and not by any other MDS variant.
> 
> This is important because the Store Buffers are partitioned between
> Hyper-Threads so cross thread forwarding is not possible. But if a thread
> enters or exits a sleep state the store buffer is repartitioned which can
> expose data from one thread to the other. This transition can be mitigated.
> 
> That means that for CPUs which are only affected by MSBDS SMT can be
> enabled, if the CPU is not affected by other SMT sensitive vulnerabilities,
> e.g. L1TF. The XEON PHI variants fall into that category.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
>  arch/x86/include/asm/cpufeatures.h |    1 +
>  arch/x86/kernel/cpu/common.c       |   10 +++++++---
>  2 files changed, 8 insertions(+), 3 deletions(-)
> 
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -383,5 +383,6 @@
>  #define X86_BUG_SPEC_STORE_BYPASS	X86_BUG(17) /* CPU is affected by speculative store bypass attack */
>  #define X86_BUG_L1TF			X86_BUG(18) /* CPU is affected by L1 Terminal Fault */
>  #define X86_BUG_MDS			X86_BUG(19) /* CPU is affected by Microarchitectural data sampling */
> +#define X86_BUG_MSBDS_ONLY		X86_BUG(20) /* CPU is only affected by the  MSDBS variant of BUG_MDS */
>  
>  #endif /* _ASM_X86_CPUFEATURES_H */
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -953,6 +953,7 @@ static void identify_cpu_without_cpuid(s
>  #define NO_SSB		BIT(2)
>  #define NO_L1TF		BIT(3)
>  #define NO_MDS		BIT(4)
> +#define MSBDS_ONLY	BIT(5)
>  
>  #define VULNWL(_vendor, _family, _model, _whitelist)	\
>  	{ X86_VENDOR_##_vendor, _family, _model, X86_FEATURE_ANY, _whitelist }
> @@ -983,8 +984,8 @@ static const __initconst struct x86_cpu_
>  	VULNWL_INTEL(ATOM_SILVERMONT_X,		NO_SSB | NO_L1TF),
>  	VULNWL_INTEL(ATOM_SILVERMONT_MID,	NO_SSB | NO_L1TF),
>  	VULNWL_INTEL(ATOM_AIRMONT,		NO_SSB | NO_L1TF),
> -	VULNWL_INTEL(XEON_PHI_KNL,		NO_SSB | NO_L1TF),
> -	VULNWL_INTEL(XEON_PHI_KNM,		NO_SSB | NO_L1TF),
> +	VULNWL_INTEL(XEON_PHI_KNL,		NO_SSB | NO_L1TF | MSBDS_ONLY),
> +	VULNWL_INTEL(XEON_PHI_KNM,		NO_SSB | NO_L1TF | MSBDS_ONLY),
>  
>  	VULNWL_INTEL(CORE_YONAH,		NO_SSB),
>  
> @@ -1033,8 +1034,11 @@ static void __init cpu_set_bug_bits(stru
>  	if (ia32_cap & ARCH_CAP_IBRS_ALL)
>  		setup_force_cpu_cap(X86_FEATURE_IBRS_ENHANCED);
>  
> -	if (!cpu_matches(NO_MDS) && !(ia32_cap & ARCH_CAP_MDS_NO))
> +	if (!cpu_matches(NO_MDS) && !(ia32_cap & ARCH_CAP_MDS_NO)) {
>  		setup_force_cpu_bug(X86_BUG_MDS);
> +		if (cpu_matches(MSBDS_ONLY))
> +			setup_force_cpu_bug(X86_BUG_MSBDS_ONLY);
> +	}
>  
>  	if (cpu_matches(NO_MELTDOWN))
>  		return;
> 

It looks weird to have it as a separate bug flag and not as a subset of full
MDS such as:

    #define NO_IDLE_SHARED_MDS BIT(4)
    #define NO_SHARED_MDS      BIT(5)
    #define NO_MDS             (NO_IDLE_SHARED_MDS | NO_SHARED_MDS)

Now that would probably make sense only if the mitigation of full MDS required
to also imply a VERW before entering idle (that's the mitigation of MSBDS_ONLY, right?).
Turning off SMT removes the need to do that so the layout seem to make sense as is.

Reviewed-by: Frederic Weisbecker <frederic@kernel.org>

  reply	other threads:[~2019-03-02  1:29 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-01 21:47 [patch V6 00/14] MDS basics 0 Thomas Gleixner
2019-03-01 21:47 ` [patch V6 01/14] MDS basics 1 Thomas Gleixner
2019-03-02  0:06   ` [MODERATED] " Frederic Weisbecker
2019-03-01 21:47 ` [patch V6 02/14] MDS basics 2 Thomas Gleixner
2019-03-02  0:34   ` [MODERATED] " Frederic Weisbecker
2019-03-02  8:34   ` Greg KH
2019-03-05 17:54   ` Borislav Petkov
2019-03-01 21:47 ` [patch V6 03/14] MDS basics 3 Thomas Gleixner
2019-03-02  1:12   ` [MODERATED] " Frederic Weisbecker
2019-03-01 21:47 ` [patch V6 04/14] MDS basics 4 Thomas Gleixner
2019-03-02  1:28   ` Frederic Weisbecker [this message]
2019-03-05 14:52     ` Thomas Gleixner
2019-03-06 20:00   ` [MODERATED] " Andrew Cooper
2019-03-06 20:32     ` Thomas Gleixner
2019-03-07 23:56   ` [MODERATED] " Andi Kleen
2019-03-08  0:36     ` Linus Torvalds
2019-03-01 21:47 ` [patch V6 05/14] MDS basics 5 Thomas Gleixner
2019-03-02  1:37   ` [MODERATED] " Frederic Weisbecker
2019-03-07 23:59   ` Andi Kleen
2019-03-08  6:37     ` Thomas Gleixner
2019-03-01 21:47 ` [patch V6 06/14] MDS basics 6 Thomas Gleixner
2019-03-04  6:28   ` [MODERATED] Encrypted Message Jon Masters
2019-03-05 14:55     ` Thomas Gleixner
2019-03-01 21:47 ` [patch V6 07/14] MDS basics 7 Thomas Gleixner
2019-03-02  2:22   ` [MODERATED] " Frederic Weisbecker
2019-03-05 15:30     ` Thomas Gleixner
2019-03-06 15:49       ` [MODERATED] " Frederic Weisbecker
2019-03-06  5:21   ` Borislav Petkov
2019-03-01 21:47 ` [patch V6 08/14] MDS basics 8 Thomas Gleixner
2019-03-03  2:54   ` [MODERATED] " Frederic Weisbecker
2019-03-04  6:57   ` [MODERATED] Encrypted Message Jon Masters
2019-03-04  7:06     ` Jon Masters
2019-03-04  8:12       ` Jon Masters
2019-03-05 15:34     ` Thomas Gleixner
2019-03-06 16:21       ` [MODERATED] " Jon Masters
2019-03-06 14:11   ` [MODERATED] Re: [patch V6 08/14] MDS basics 8 Borislav Petkov
2019-03-01 21:47 ` [patch V6 09/14] MDS basics 9 Thomas Gleixner
2019-03-06 16:14   ` [MODERATED] " Frederic Weisbecker
2019-03-01 21:47 ` [patch V6 10/14] MDS basics 10 Thomas Gleixner
2019-03-04  6:45   ` [MODERATED] Encrypted Message Jon Masters
2019-03-05 18:42   ` [MODERATED] Re: [patch V6 10/14] MDS basics 10 Andrea Arcangeli
2019-03-06 19:15     ` Thomas Gleixner
2019-03-06 14:31   ` [MODERATED] " Borislav Petkov
2019-03-06 15:30     ` Thomas Gleixner
2019-03-06 18:35       ` Thomas Gleixner
2019-03-06 19:34         ` [MODERATED] Re: " Borislav Petkov
2019-03-01 21:47 ` [patch V6 11/14] MDS basics 11 Thomas Gleixner
2019-03-01 21:47 ` [patch V6 12/14] MDS basics 12 Thomas Gleixner
2019-03-04  5:47   ` [MODERATED] Encrypted Message Jon Masters
2019-03-05 16:04     ` Thomas Gleixner
2019-03-05 16:40   ` [MODERATED] Re: [patch V6 12/14] MDS basics 12 mark gross
2019-03-06 14:42   ` Borislav Petkov
2019-03-01 21:47 ` [patch V6 13/14] MDS basics 13 Thomas Gleixner
2019-03-03  4:01   ` [MODERATED] " Josh Poimboeuf
2019-03-05 16:04     ` Thomas Gleixner
2019-03-05 16:43   ` [MODERATED] " mark gross
2019-03-01 21:47 ` [patch V6 14/14] MDS basics 14 Thomas Gleixner
2019-03-01 23:48 ` [patch V6 00/14] MDS basics 0 Thomas Gleixner
2019-03-04  5:30 ` [MODERATED] Encrypted Message Jon Masters

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=20190302012854.GD22355@lenoir \
    --to=frederic@kernel.org \
    --cc=speck@linutronix.de \
    /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.