historical-speck.lore.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: ...
Date: Mon, 21 Oct 2019 22:53:10 -0700	[thread overview]
Message-ID: <20191022055310.GA12194@guptapadev.amr> (raw)
In-Reply-To: <4f718d5b-b578-ddd9-9898-36c6088a4615@redhat.com>

On Tue, Oct 22, 2019 at 12:10:31AM -0400, speck for Jon Masters wrote:
> Subject: Re: [PATCH v7 07/10] TAAv7 7

> On 10/21/19 4:29 PM, speck for Pawan Gupta wrote:
> > From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> > Subject: [PATCH v7 07/10] x86/tsx: Add "auto" option to TSX cmdline parameter
> > 
> > Platforms which are not affected by X86_BUG_TAA may want the TSX feature
> > enabled. Add "auto" option to the TSX cmdline parameter. When tsx=auto
> > disable TSX when X86_BUG_TAA is present, otherwise enable TSX.
> 
> Earlier, you do this:
> 
> +	if (!(ia32_cap & ARCH_CAP_TAA_NO) &&
> +	    (boot_cpu_has(X86_FEATURE_RTM) ||
> +	     (ia32_cap & ARCH_CAP_TSX_CTRL_MSR)))
> +		setup_force_cpu_bug(X86_BUG_TAA);
> 
> Per the other discussion, I think you want to double check if tsx=auto
> is doing what folks want it to do, because currently I think auto still
> has the semantics of turning off TSX on everything, rather than just
> those cases where a VERW mitigation won't suffice/is in use.

tsx=auto can only disable TSX on current CPUs(MDS_NO=1) because older
CPUs(MDS_NO=0) wont get TSX_CTRL_MSR.

On older CPUs tsx_init() would simply do nothing because of lack of TSX_CTRL. 

	void __init tsx_init(void)
	{
		if (!tsx_ctrl_is_supported())
			return;
	[...]

> 
> (see Thomas's update to the "Re: [PATCH v5 08/11] TAAv5 8" diagram)

  MDS_NO        MD_CLEAR        TSX_CTRL_MSR
    0             0                 0           Vulnerable (needs ucode)
    0             1                 0           MDS and TAA mitigated via VERW
    1             1                 0           MDS fixed, TAA vulnerable if TSX enabled
                                                because MD_CLEAR has no meaning and
                                                VERW is not guaranteed to clear buffers
    1             X                 1           MDS fixed, TAA can be mitigated by
                                                           VERW or TSX_CTRL_MSR

Thomas's table sums up the mitigation status.

> 
> It seems that it's a good time to double check if that's what everyone
> on the distro side is expecting, namely "tsx=auto will disable TSX
> automatically on those parts impacted by TAA for which VERW mitigation
> is not available".

Microcode update for MDS_NO=1 parts adds both TSX_CTRL and VERW
mitigation at the same time. It is for the OS to choose(tsx=) which
mitigation to deploy. 

For MDS_NO=0 CPUs:
	VERW mitigation will be deployed.
	tsx= is ineffective, for the lack of TSX_CTRL.

For MDS_NO=1 CPUs:
	If OS chooses tsx=on, VERW mitigation will be deployed.
	If OS chooses tsx=auto, TSX will be disabled.
	If OS chooses tsx=off, TSX will be disabled (for TAA_NO=1 as well).

More details on tsx=auto:

+----------+----------+----------------+---------------+--------------+-------------------+
|  MSR_IA32_ARCH_CAPABILITIES bits     |           Result with cmdline tsx=auto           |
+----------+----------+----------------+---------------+--------------+-------------------+
|  TAA_NO  |  MDS_NO  |  TSX_CTRL_MSR  |  VERW clears  |  TSX state   |  TAA mitigation   |
|          |          |                |  CPU buffers  | after bootup |                   |
+==========+==========+================+===============+==============+===================+
|    0     |    0     |       0        |      Yes      |  HW default  |    Same as MDS    |
+----------+----------+----------------+---------------+--------------+-------------------+
|    0     |    0     |       1        | Invalid case  | Invalid case |   Invalid case    |
+----------+----------+----------------+---------------+--------------+-------------------+
|    0     |    1     |       0        |      No       |  HW default  | Need ucode update |
+----------+----------+----------------+---------------+--------------+-------------------+
|    0     |    1     |       1        |      Yes      | TSX disabled |   TSX disabled    |
+----------+----------+----------------+---------------+--------------+-------------------+
|    1     |    X     |       1        |       X       | TSX enabled  |    None needed    |
+----------+----------+----------------+---------------+--------------+-------------------+

Note: MDS_NO=0 and TSX_CTRL_MSR=1 is an invalid case above, which
prevents tsx=auto from disabling TSX in older CPUs.

>This seems to reduce the set where we end up
> disabling TSX essentially to a few very recent processors (e.g.
> CascadeLake some second gen, Bx stepping?). If that's what we are all
> expecting/are planning to do, I suspect Red Hat would go with tsx=auto
> as a default since the set of impacted processors can be documented.
> 
> Anyway, auto isn't right yet.

Below change isn't required as per the above explanation, but I can add
it if adds clarity. Or maybe cover with code comments.

diff --git a/arch/x86/kernel/cpu/tsx.c b/arch/x86/kernel/cpu/tsx.c
index 0969e6e9dff3..7b567ca266c9 100644
--- a/arch/x86/kernel/cpu/tsx.c
+++ b/arch/x86/kernel/cpu/tsx.c
@@ -70,7 +70,8 @@ static bool __init tsx_ctrl_is_supported(void)
 
 static enum tsx_ctrl_states x86_get_tsx_auto_mode(void)
 {
-	if (boot_cpu_has_bug(X86_BUG_TAA))
+	if (boot_cpu_has_bug(X86_BUG_TAA) &&
+	    (ARCH_CAP_MDS_NO & x86_read_arch_cap_msr()))
 		return TSX_CTRL_DISABLE;
 
 	return TSX_CTRL_ENABLE;

  reply	other threads:[~2019-10-22  5:59 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-21 20:22 [MODERATED] [PATCH v7 00/10] TAAv7 0 Pawan Gupta
2019-10-21 20:23 ` [MODERATED] [PATCH v7 01/10] TAAv7 1 Pawan Gupta
2019-10-21 20:24 ` [MODERATED] [PATCH v7 02/10] TAAv7 2 Pawan Gupta
2019-10-21 20:25 ` [MODERATED] [PATCH v7 03/10] TAAv7 3 Pawan Gupta
2019-10-21 20:26 ` [MODERATED] [PATCH v7 04/10] TAAv7 4 Pawan Gupta
2019-10-21 20:27 ` [MODERATED] [PATCH v7 05/10] TAAv7 5 Pawan Gupta
2019-10-21 20:28 ` [MODERATED] [PATCH v7 06/10] TAAv7 6 Pawan Gupta
2019-10-21 20:29 ` [MODERATED] [PATCH v7 07/10] TAAv7 7 Pawan Gupta
2019-10-21 20:30 ` [MODERATED] [PATCH v7 08/10] TAAv7 8 Pawan Gupta
2019-10-21 20:31 ` [MODERATED] [PATCH v7 09/10] TAAv7 9 Michal Hocko
2019-10-21 20:32 ` [MODERATED] [PATCH v7 10/10] TAAv7 10 Pawan Gupta
2019-10-21 21:32 ` [MODERATED] Re: [PATCH v7 00/10] TAAv7 0 Andy Lutomirski
2019-10-21 23:06   ` Andrew Cooper
2019-10-22  0:34   ` Pawan Gupta
2019-10-22  4:10 ` [MODERATED] Jon Masters
2019-10-22  5:53   ` Pawan Gupta [this message]
2019-10-22  7:58 ` [MODERATED] Re: ***UNCHECKED*** [PATCH v7 07/10] TAAv7 7 Michal Hocko
2019-10-22 16:55   ` [MODERATED] " Pawan Gupta
2019-10-22  8:00 ` [MODERATED] Re: ***UNCHECKED*** [PATCH v7 09/10] TAAv7 9 Michal Hocko
2019-10-22  8:15 ` [MODERATED] Re: ***UNCHECKED*** [PATCH v7 03/10] TAAv7 3 Michal Hocko
2019-10-22 14:42   ` Josh Poimboeuf
2019-10-22 16:48     ` [MODERATED] " Pawan Gupta
2019-10-22 17:01       ` [MODERATED] Re: ***UNCHECKED*** " Michal Hocko
2019-10-22 17:35         ` Josh Poimboeuf
2019-10-22 14:38 ` [MODERATED] " Borislav Petkov
2019-10-22 16:58   ` Pawan Gupta
2019-10-22 14:48 ` Borislav Petkov
2019-10-22 17:00   ` Pawan Gupta
2019-10-22 17:16     ` [MODERATED] " Borislav Petkov
2019-10-22 18:07       ` [MODERATED] " Pawan Gupta
2019-10-22 15:07 ` Borislav Petkov
2019-10-22 18:36   ` Pawan Gupta
2019-10-22 18:59     ` [MODERATED] " Borislav Petkov
2019-10-22 16:51 ` [MODERATED] Re: [PATCH v7 04/10] TAAv7 4 Borislav Petkov
2019-10-22 17:02   ` Borislav Petkov
2019-10-22 18:00     ` Pawan Gupta
2019-10-22 18:12       ` [MODERATED] " Borislav Petkov
2019-10-22 19:16         ` Luck, Tony
2019-10-22 19:28           ` [MODERATED] " Borislav Petkov
2019-10-22 20:02             ` Luck, Tony
2019-10-22 20:48               ` [MODERATED] Jon Masters
2019-10-22 20:54               ` [MODERATED] Re: [PATCH v7 04/10] TAAv7 4 Borislav Petkov
2019-10-22 21:38                 ` Josh Poimboeuf
2019-10-22 21:46                   ` Borislav Petkov
2019-10-22 22:06                     ` Josh Poimboeuf
2019-10-22 22:13                       ` Borislav Petkov
2019-10-22 17:44   ` Pawan Gupta
2019-10-22 19:04     ` [MODERATED] " Borislav Petkov
2019-10-22 21:29       ` [MODERATED] " Pawan Gupta
2019-10-22 21:53         ` Borislav Petkov
2019-10-22 22:05           ` Borislav Petkov
2019-10-23  0:27             ` Pawan Gupta
2019-10-23  5:25               ` Pawan Gupta
2019-10-23  6:46                 ` Borislav Petkov
2019-10-23 13:28                   ` Pawan Gupta
2019-10-23 14:39                     ` Borislav Petkov
2019-10-23  1:33   ` Pawan Gupta
2019-10-23  6:48     ` Borislav Petkov
2019-10-22 17:25 ` [MODERATED] Re: [PATCH v7 01/10] TAAv7 1 Josh Poimboeuf
2019-10-23  9:26   ` Borislav Petkov
2019-10-22 17:26 ` Josh Poimboeuf
2019-10-22 20:44   ` [MODERATED] Jon Masters
2019-10-22 17:47 ` [MODERATED] Re: [PATCH v7 03/10] TAAv7 3 Josh Poimboeuf
2019-10-22 18:39 ` [MODERATED] Re: [PATCH v7 10/10] TAAv7 10 Josh Poimboeuf
2019-10-23  7:24   ` Borislav Petkov
2019-10-22 21:20 ` [MODERATED] Re: [PATCH v7 04/10] TAAv7 4 Josh Poimboeuf
2019-10-22 21:35   ` Andrew Cooper
2019-10-22 21:44     ` Josh Poimboeuf
2019-10-22 22:03       ` Andrew Cooper
2019-10-23  1:16         ` Josh Poimboeuf
2019-10-23 15:46 ` [MODERATED] Re: [PATCH v7 00/10] TAAv7 0 Borislav Petkov
2019-10-23 17:11   ` Josh Poimboeuf
2019-10-23 21:49     ` Borislav Petkov
2019-10-23 22:12   ` Pawan Gupta
2019-10-24 14:08     ` Borislav Petkov
     [not found] ` <5dae165e.1c69fb81.4beee.e271SMTPIN_ADDED_BROKEN@mx.google.com>
2019-10-24 20:53   ` [MODERATED] Re: [PATCH v7 06/10] TAAv7 6 Paolo Bonzini
2019-10-24 21:00     ` Luck, Tony
2019-10-24 21:33       ` Paolo Bonzini
  -- strict thread matches above, loose matches on Subject: below --
2019-02-19 15:58 [MODERATED] [PATCH 0/4] walnut 0 Peter Zijlstra
2019-02-19 15:58 ` [MODERATED] [PATCH 4/4] walnut 4 Peter Zijlstra
2019-02-19 18:49   ` [MODERATED] Linus Torvalds
2019-02-20 14:37     ` Peter Zijlstra

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=20191022055310.GA12194@guptapadev.amr \
    --to=pawan.kumar.gupta@linux.intel.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).