historical-speck.lore.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH 8/9] TAA 8
Date: Thu, 24 Oct 2019 11:03:12 -0500	[thread overview]
Message-ID: <20191024160312.auyqdk5geednwmdt@treble> (raw)
In-Reply-To: <5b426d6ab55e7aa9efc33f0e3eefe84419a18c56.1571905227.git.bp@suse.de>

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?

> +
> +In all other cases, if the host either does not have the TAA microcode or the
> +kernel is not mitigated, the system might be vulnerable.
> +
> +
> +.. _taa_mitigation_control_command_line:
> +
> +Mitigation control on the kernel command line
> +---------------------------------------------
> +
> +The kernel command line allows to control the TAA mitigations at boot time with
> +the option "tsx_async_abort=". The valid arguments for this option are:
> +
> +  ============  =============================================================
> +  off		This option disables the TAA mitigation on affected platforms.
> +                If the system has TSX enabled (see next parameter) and the CPU
> +                is affected, the system is vulnerable.
> +
> +  full	        TAA mitigation is enabled. If TSX is enabled, on an affected
> +                system it will clear CPU buffers on ring transitions. On
> +                systems which are MDS-affected and deploy MDS mitigation,
> +                TAA is also mitigated. Specifying this option on those
> +                systems will have no effect.
> +
> +  full,nosmt    The same as tsx_async_abort=full, with SMT disabled on
> +                vulnerable CPUs that have TSX enabled. This is the complete
> +                mitigation. When TSX is disabled, SMT is not disabled because
> +                CPU is not vulnerable to cross-thread TAA attacks.
> +  ============  =============================================================
> +
> +Not specifying this option is equivalent to "tsx_async_abort=full".
> +
> +The kernel command line also allows to control the TSX feature using the
> +parameter "tsx=" on CPUs which support TSX control. MSR_IA32_TSX_CTRL is used
> +to control the TSX feature and the enumeration of the TSX feature bits (RTM
> +and HLE) in CPUID.
> +
> +The valid options are:
> +
> +  ============  =============================================================
> +  off		Disables TSX.
> +

This is not universally true.

> +  on		Enables TSX.

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

> +
> +  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.

> +  ============  =============================================================
> +
> +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.

> +
> +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?

> +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) ?

> +    1          X            1        MDS fixed, TAA can be mitigated by
> +                                     VERW or TSX_CTRL_MSR
> +  =======  =========  =============  ========================================
> +
> +Mitigation selection guide
> +--------------------------
> +
> +1. Trusted userspace and guests
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +If all user space applications are from a trusted source and do not execute
> +untrusted code which is supplied externally, then the mitigation can be
> +disabled. The same applies to virtualized environments with trusted guests.
> +
> +
> +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 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?

> +
> +
> +.. _taa_default_mitigations:
> +
> +Default mitigations
> +-------------------
> +
> +The kernel's default action for vulnerable processors is:
> +
> +  - Deploy TSX disable mitigation (tsx_async_abort=full tsx=off).
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index e1aca10f2a7f..6eb1c0c8018c 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2636,6 +2636,7 @@
>  					       ssbd=force-off [ARM64]
>  					       l1tf=off [X86]
>  					       mds=off [X86]
> +					       tsx_async_abort=off [X86]
>  
>  			auto (default)
>  				Mitigate all CPU vulnerabilities, but leave SMT
> @@ -2651,6 +2652,7 @@
>  				be fully mitigated, even if it means losing SMT.
>  				Equivalent to: l1tf=flush,nosmt [X86]
>  					       mds=full,nosmt [X86]
> +					       tsx_async_abort=full,nosmt [X86]
>  
>  	mminit_loglevel=
>  			[KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this
> @@ -4864,6 +4866,40 @@
>  
>  			Not specifying this option is equivalent to tsx=off.
>  
> +	tsx_async_abort= [X86,INTEL] Control mitigation for the TSX Async
> +			Abort (TAA) vulnerability.
> +
> +			Similar to Micro-architectural Data Sampling (MDS)
> +			certain CPUs that support Transactional
> +			Synchronization Extensions (TSX) are vulnerable to an
> +			exploit against CPU internal buffers which can forward
> +			information to a disclosure gadget under certain
> +			conditions.
> +
> +			In vulnerable processors, the speculatively forwarded
> +			data can be used in a cache side channel attack, to
> +			access data to which the attacker does not have direct
> +			access.
> +
> +			This parameter controls the TAA mitigation.  The
> +			options are:
> +
> +			full       - Enable TAA mitigation on vulnerable CPUs

if TSX is disabled

> +			full,nosmt - Enable TAA mitigation and disable SMT on
> +				     vulnerable CPUs. If TSX is disabled, SMT
> +				     is not disabled because CPU is not
> +				     vulnerable to cross-thread TAA attacks.
> +			off        - Unconditionally disable TAA mitigation
> +
> +			Not specifying this option is equivalent to
> +			tsx_async_abort=full.  On CPUs which are MDS affected
> +			and deploy MDS mitigation, TAA mitigation is not
> +			required and doesn't provide any additional
> +			mitigation.
> +
> +			For details see:
> +			Documentation/admin-guide/hw-vuln/tsx_async_abort.rst
> +
>  	turbografx.map[2|3]=	[HW,JOY]
>  			TurboGraFX parallel port interface
>  			Format:
> diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst
> index af64c4bb4447..a8de2fbc1caa 100644
> --- a/Documentation/x86/index.rst
> +++ b/Documentation/x86/index.rst
> @@ -27,6 +27,7 @@ x86-specific Documentation
>     mds
>     microcode
>     resctrl_ui
> +   tsx_async_abort
>     usb-legacy-support
>     i386/index
>     x86_64/index
> diff --git a/Documentation/x86/tsx_async_abort.rst b/Documentation/x86/tsx_async_abort.rst
> new file mode 100644
> index 000000000000..583ddc185ba2
> --- /dev/null
> +++ b/Documentation/x86/tsx_async_abort.rst
> @@ -0,0 +1,117 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +TSX Async Abort (TAA) mitigation
> +================================
> +
> +.. _tsx_async_abort:
> +
> +Overview
> +--------
> +
> +TSX Async Abort (TAA) is a side channel attack on internal buffers in some
> +Intel processors similar to Microachitectural Data Sampling (MDS).  In this
> +case certain loads may speculatively pass invalid data to dependent operations
> +when an asynchronous abort condition is pending in a Transactional
> +Synchronization Extensions (TSX) transaction.  This includes loads with no
> +fault or assist condition. Such loads may speculatively expose stale data from
> +the same uarch data structures as in MDS, with same scope of exposure i.e.
> +same-thread and cross-thread. This issue affects all current processors that
> +support TSX.
> +
> +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?

> +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.

> +
> +Kernel internal mitigation modes
> +--------------------------------
> +
> + =============    ============================================================
> + off              Mitigation is disabled. Either the CPU is not affected or
> +                  tsx_async_abort=off is supplied on the kernel command line.
> +
> + tsx disabled     Mitigation is enabled. TSX feature is disabled by default at
> +                  bootup on processors that support TSX control.
> +
> + verw             Mitigation is enabled. CPU is affected and MD_CLEAR is
> +                  advertised in CPUID.
> +
> + ucode needed     Mitigation is enabled. CPU is affected and MD_CLEAR is not
> +                  advertised in CPUID. That is mainly for virtualization
> +                  scenarios where the host has the updated microcode but the
> +                  hypervisor does not expose MD_CLEAR in CPUID. It's a best
> +                  effort approach without guarantee.
> + =============    ============================================================
> +
> +If the CPU is affected and the "tsx_async_abort" kernel command line parameter is
> +not provided then the kernel selects an appropriate mitigation depending on the
> +status of RTM and MD_CLEAR CPUID bits.
> +
> +Below tables indicate the impact of tsx=on|off|auto cmdline options on state of
> +TAA mitigation, VERW behavior and TSX feature for various combinations of
> +MSR_IA32_ARCH_CAPABILITIES bits.
> +
> +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"?

-- 
Josh

  reply	other threads:[~2019-10-24 16:28 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   ` Josh Poimboeuf [this message]
2019-10-24 17:35     ` [MODERATED] " Borislav Petkov
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=20191024160312.auyqdk5geednwmdt@treble \
    --to=jpoimboe@redhat.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).