historical-speck.lore.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@suse.de>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH 8/9] TAA 8
Date: Thu, 24 Oct 2019 19:35:38 +0200	[thread overview]
Message-ID: <20191024173538.GG14115@zn.tnic> (raw)
In-Reply-To: <20191024160312.auyqdk5geednwmdt@treble>

On Thu, Oct 24, 2019 at 11:03:12AM -0500, speck for Josh Poimboeuf wrote:
> On Wed, Oct 23, 2019 at 12:32:55PM +0200, speck for Pawan Gupta wrote:
> > +Virtualization mitigation
> > +^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +Affected systems where the host has the TAA microcode and the TAA mitigation is
> > +ON (with TSX disabled) are not vulnerable regardless of the status of the VMs.
> 
> This is is confusing: "the TAA mitigation is ON (with TSX disabled)".
> 
> Which is it?  Is the TAA mitigation on, or is TSX disabled?

I think it wants to say:

"Affected systems where the host has TAA microcode and TAA is mitigated
by having disabled TSX, are not vulnerable..."

> This is not universally true.

			"Disables TSX on systems which have the TSX-disable MSR."

> 
> > +  on		Enables TSX.
> 
> This probably needs the same "TSX is fundamentally insecure" caveat I
> proposed for kernel-parameters.txt.

I'm great at copy'n'paste:

			"Enables TSX.

			Although there are mitigations for all known security
			vulnerabilities, TSX has been known to be an accelerator
			for several previous speculation-related CVEs, and so
			there may be unknown security risks associated with leaving
			it enabled."

> 
> > +
> > +  auto		Disables TSX on affected platform, otherwise enables TSX.
> 
> This is not universally true.
> 
> Also, it would be relevant to refer to that table Pawan posted which
> shows exactly which CPUs are vulnerable to TAA but not MDS.

This one?

I don't know whether this one will get more models later or what the
TAA_NO plan is...

+----------------------------+------------------+------------+
|            Name            |  Family / model  |  Stepping  |
+============================+==================+============+
| Whiskey Lake (ULT refresh) |      06_8E       |    0xC     |
+----------------------------+------------------+------------+
|    2nd gen Cascade Lake    |      06_55       |    6, 7    |
+----------------------------+------------------+------------+
|       Coffee Lake R        |      06_9E       |    0xD     |
+----------------------------+------------------+------------+


> 
> > +  ============  =============================================================
> > +
> > +Not specifying this option is equivalent to "tsx=off".
> > +
> > +The following combinations of the "tsx_async_abort" and "tsx" are possible. For
> > +affected platforms tsx=auto is equivalent to tsx=off and the result will be:
> > +
> > +  =========  ====================   =========================================
> > +  tsx=on     tsx_async_abort=full   The system will use VERW to clear CPU
> > +                                    buffers.
> 
> The system may still be vulnerable to SMT-based attacks.
> 
> > +  tsx=on     tsx_async_abort=off    The system is vulnerable.
> > +  tsx=off    tsx_async_abort=full   TSX is disabled. System is not vulnerable.
> > +  tsx=off    tsx_async_abort=off    TSX is disabled. System is not vulnerable.
> > +  =========  ====================   =========================================
> 
> Combinations with tsx_async_abort=full,nosmt should also be described.

  =========  ====================   =========================================
  tsx=on     tsx_async_abort=full   The system will use VERW to clear CPU
                                    buffers. Cross-thread attacks still possible
                                    on SMT machines.
  tsx=on     tsx_async_abort=full,nosmt As above, cross-thread attacks on SMT
                                    mitigated.
  tsx=on     tsx_async_abort=off    The system is vulnerable.
  tsx=off    tsx_async_abort=full   TSX is disabled. System is not vulnerable.
  tsx=off    tsx_async_abort=full,nosmt ditto
  tsx=off    tsx_async_abort=off    ditto
  =========  ====================   =========================================


> > +For unaffected platforms "tsx=on" and "tsx_async_abort=full" does not clear CPU
> > +buffers.  For platforms without TSX control "tsx" command line argument has no
> > +effect.
> 
> Which platforms are those?

The MDS_NO=0 ones.

> 
> > +For the affected platforms below table indicates the mitigation status for the
> > +combinations of CPUID bit MD_CLEAR and IA32_ARCH_CAPABILITIES MSR bits MDS_NO
> > +and TSX_CTRL_MSR.
> > +
> > +  =======  =========  =============  ========================================
> > +  MDS_NO   MD_CLEAR   TSX_CTRL_MSR   Status
> > +  =======  =========  =============  ========================================
> > +    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
> 
> (needs ucode) ?

Will there even be microcode for those to beef up VERW?

> > +2. Untrusted userspace and guests
> > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +If there are untrusted applications or guests on the system, enabling TSX
> > +might allow a malicious actor to leak data from the host or from other
> > +processes running on the same physical core.
> 
> Unless the mitigation is enabled (which is on by default, BTW...)
> 
> This makes it sounds like the only mitigation is to disable TSX.

"If there are untrusted applications or guests on the system, enabling
TSX and the inability to enable the TAA mitigation (missing microcode
for a particular model, etc.) might allow a malicious actor to leak
data from the host or from other processes running on the same physical
core."

> > +If the microcode is available and the TSX is disabled on the host, attacks
> > +are prevented in a virtualized environment as well, even if the VMs do not
> > +explicitly enable the mitigation.
> 
> What's the effect on VM security if TSX is enabled and the host TAA
> mitigation is also enabled?

Same as in the !VM case, I'd assume. tsx_async_abort=full,nosmt should
give you full mitigation.

> > +			This parameter controls the TAA mitigation.  The
> > +			options are:
> > +
> > +			full       - Enable TAA mitigation on vulnerable CPUs
> 
> if TSX is disabled

No, that's TAA_MITIGATION_VERW which does the buffer clearing.

> > +Mitigation strategy
> > +-------------------
> > +
> > +a) TSX disable - one of the mitigations is to disable TSX. A new MSR
> > +IA32_TSX_CTRL will be available in future and current processors after
> 
> which processors?

The MDS_NO=1 and future parts, I guess.

> 
> > +microcode update which can be used to disable TSX. In addition, it
> > +controls the enumeration of the TSX feature bits (RTM and HLE) in CPUID.
> > +
> > +b) Clear CPU buffers - similar to MDS, clearing the CPU buffers mitigates this
> > +vulnerability. More details on this approach can be found in
> > +:ref:`Documentation/admin-guide/hw-vuln/mds.rst <mds>`.
> 
> It should be clarified the mitigation is a) OR b), not both.

Yah, the default one is b).

        if (boot_cpu_has(X86_FEATURE_MD_CLEAR))
                taa_mitigation = TAA_MITIGATION_VERW;
        else
                taa_mitigation = TAA_MITIGATION_UCODE_NEEDED;

unless nothing has been specified on the cmdline and it depends on what
CONFIG_X86_INTEL_TSX_MODE* has been enabled in .config. I know, it is a
mouthful.

> > +1. "tsx=off"
> > +
> > +=========  =========  ============  ============  ==============  ===================  ======================
> > +MSR_IA32_ARCH_CAPABILITIES bits     Result with cmdline tsx=off
> > +----------------------------------  -------------------------------------------------------------------------
> > +TAA_NO     MDS_NO     TSX_CTRL_MSR  TSX state     VERW can clear  TAA mitigation       TAA mitigation
> > +                                    after bootup  CPU buffers     tsx_async_abort=off  tsx_async_abort=full
> > +=========  =========  ============  ============  ==============  ===================  ======================
> > +    0          0           0         HW default         Yes           Same as MDS           Same as MDS
> 
> Does "HW default" mean "Enabled"?

I'd assume coming out of reset, TSX is enabled. Question for Intel
folks.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
-- 

  reply	other threads:[~2019-10-24 17:35 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-24  8:20 [MODERATED] [PATCH 0/9] TAA 0 Borislav Petkov
2019-10-23  8:45 ` [MODERATED] [PATCH 1/9] TAA 1 Pawan Gupta
2019-10-24 15:22   ` [MODERATED] " Josh Poimboeuf
2019-10-24 16:23     ` Borislav Petkov
2019-10-24 16:42       ` Josh Poimboeuf
2019-10-23  8:52 ` [MODERATED] [PATCH 2/9] TAA 2 Pawan Gupta
2019-10-23  9:01 ` [MODERATED] [PATCH 3/9] TAA 3 Pawan Gupta
2019-10-24 15:30   ` [MODERATED] " Josh Poimboeuf
2019-10-24 16:33     ` Borislav Petkov
2019-10-24 16:43       ` Josh Poimboeuf
2019-10-24 17:39   ` Andrew Cooper
2019-10-24 19:45     ` Borislav Petkov
2019-10-24 19:59       ` Josh Poimboeuf
2019-10-24 20:05         ` Borislav Petkov
2019-10-24 20:14           ` Josh Poimboeuf
2019-10-24 20:36             ` Borislav Petkov
2019-10-24 20:43               ` Andrew Cooper
2019-10-24 20:55                 ` Borislav Petkov
2019-10-24 20:44               ` Josh Poimboeuf
2019-10-24 20:07       ` Andrew Cooper
2019-10-24 20:17         ` Borislav Petkov
2019-10-24 22:38           ` Andrew Cooper
2019-10-25  6:03             ` Pawan Gupta
2019-10-25  7:25               ` Borislav Petkov
2019-10-25  7:17             ` Borislav Petkov
2019-10-25  9:08               ` Andrew Cooper
2019-10-27  7:48                 ` Borislav Petkov
2019-10-27  7:49                   ` [MODERATED] [AUTOREPLY] [MODERATED] [AUTOREPLY] Automatic reply: " James, Hengameh M
2019-10-24 19:47     ` [MODERATED] " Pawan Gupta
2019-10-30 13:28   ` Greg KH
2019-10-30 14:48     ` [MODERATED] Re: ***UNCHECKED*** " Michal Hocko
2019-10-30 17:24     ` [MODERATED] " Pawan Gupta
2019-10-30 19:27       ` Greg KH
2019-10-30 19:44         ` [MODERATED] Re: ***UNCHECKED*** " Michal Hocko
2019-11-01  9:35           ` Greg KH
2019-11-01 13:15             ` [MODERATED] " Borislav Petkov
2019-11-01 14:33               ` Greg KH
2019-11-01 18:42             ` [MODERATED] Re: ***UNCHECKED*** " Michal Hocko
2019-10-23  9:30 ` [MODERATED] [PATCH 4/9] TAA 4 Pawan Gupta
2019-10-24 15:32   ` [MODERATED] " Josh Poimboeuf
2019-10-24 16:43     ` Borislav Petkov
2019-10-24 17:15       ` Josh Poimboeuf
2019-10-24 17:23         ` Pawan Gupta
2019-10-24 17:27           ` Pawan Gupta
2019-10-24 17:34           ` Josh Poimboeuf
2019-10-24 18:23       ` Andrew Cooper
2019-10-24 18:56         ` Josh Poimboeuf
2019-10-24 18:59           ` Josh Poimboeuf
2019-10-24 19:13           ` Andrew Cooper
2019-10-24 19:49             ` Josh Poimboeuf
2019-10-24 20:48               ` Andrew Cooper
2019-10-25  9:12                 ` Andrew Cooper
2019-10-25  0:49   ` Pawan Gupta
2019-10-25  7:36     ` Borislav Petkov
2019-10-23 10:19 ` [MODERATED] [PATCH 5/9] TAA 5 Pawan Gupta
2019-10-24 18:30   ` [MODERATED] " Greg KH
2019-10-23 10:23 ` [MODERATED] [PATCH 6/9] TAA 6 Pawan Gupta
2019-10-23 10:28 ` [MODERATED] [PATCH 7/9] TAA 7 Pawan Gupta
2019-10-24 15:35   ` [MODERATED] " Josh Poimboeuf
2019-10-24 16:42     ` Borislav Petkov
2019-10-24 18:20       ` Jiri Kosina
2019-10-24 19:53         ` Borislav Petkov
2019-10-24 20:02           ` Josh Poimboeuf
2019-10-24 20:08             ` Borislav Petkov
2019-10-23 10:32 ` [MODERATED] [PATCH 8/9] TAA 8 Pawan Gupta
2019-10-24 16:03   ` [MODERATED] " Josh Poimboeuf
2019-10-24 17:35     ` Borislav Petkov [this message]
2019-10-24 18:11       ` Josh Poimboeuf
2019-10-24 18:55         ` Pawan Gupta
2019-10-25  8:04         ` Borislav Petkov
2019-10-23 10:35 ` [MODERATED] [PATCH 9/9] TAA 9 Michal Hocko
2019-10-24 16:10   ` [MODERATED] " Josh Poimboeuf
2019-10-24 16:58     ` Borislav Petkov
2019-10-25 10:47       ` [MODERATED] Re: ***UNCHECKED*** " Michal Hocko
2019-10-25 13:05       ` [MODERATED] " Josh Poimboeuf

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=20191024173538.GG14115@zn.tnic \
    --to=bp@suse.de \
    --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).