[MODERATED] Re: [PATCH 8/9] TAA 8

[Josh Poimboeuf <jpoimboe@redhat.com>]

On Thu, Oct 24, 2019 at 07:35:38PM +0200, speck for Borislav Petkov wrote:
> 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."

Maybe use the same wording from kernel-parameters.txt?

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

Ditto, I guess whatever wording is used in kernel-parameters.txt can be
cribbed for here.

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

That's the one, but yeah... it might not be future-complete, and even if
it is, Intel probably doesn't want to disclose that anyway.

> > > +  ============  =============================================================
> > > +
> > > +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 _might_ be disabled, depending...

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

Right, update the wording?

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

This might be a question for Intel, but I assumed this is the case where
the new microcode on the MDS_NO parts would enable the VERW buffer
clearing.

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

Right, the effects of the host mitigation options on the guest would be
useful here.

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

I meant to say "if TSX is enabled".  Otherwise if TSX is disabled this
option doesn't do anything

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

Right, that should be clarified.

-- 
Josh