diff mbox series

[v3,2/2] qemu-cpu-models.rst: Document -noTSX, mds-no, taa-no, and tsx-ctrl

Message ID 20200220142001.20774-3-kchamart@redhat.com
State New
Headers show
Series qemu-cpu-models: Convert to rST; document other MSR bits | expand

Commit Message

Kashyap Chamarthy Feb. 20, 2020, 2:20 p.m. UTC 
- Add the '-noTSX' variants for CascadeLake and SkyLake.

- Document the three MSR bits: 'mds-no', 'taa-no', and 'tsx-ctrl'

  Two confusing things about 'mds-no' (and the first point applies to
  the other two MSRs too):

  (1) The 'mds-no' bit will _not_ show up in the guest's /proc/cpuinfo.
      Rather it is used to fill in the guest's sysfs:

        /sys/devices/system/cpu/vulnerabilities/mds:Not affected

      Paolo confirmed on IRC as such.

  (2) There are _three_ variants[+] of CascadeLake CPUs, with different
      stepping levels: 5, 6, and 7.  To quote wikichip.org[*]:

        "note that while steppings 6 & 7 are fully mitigated, earlier
        stepping 5 is not protected against MSBDS, MLPDS, nor MDSUM"

      The above is also indicated in the Intel's document[+], as
      indicated by "No" under the three columns of MFBDS, MSBDS, and
      MLPDS.

  I've expressed this in the docs without belabouring the details.

      [+] https://software.intel.com/security-software-guidance/insights/processors-affected-microarchitectural-data-sampling
      [*] https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#Key_changes_from_Skylake

Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
---
---
[Retaining parts of the change-log from the Texinfo-variant of this patch,
which is now no-longer needed:
https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg06455.html]

v3:
 - Makefile, Sphinx and related fixes (Peter Maydell)
 - Address feedback from Paolo
 - Add URL to the deep-dive on Intel's MDS
v2:
 - Address feedback from DanPB
 - Add sections on 'taa-no' and 'tsx-ctrl'
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
---
 docs/system/qemu-cpu-models.rst | 57 +++++++++++++++++++++++++++++++++
 1 file changed, 57 insertions(+)

Comments

Paolo Bonzini Feb. 20, 2020, 2:52 p.m. UTC | #1 
Two small changes...

On 20/02/20 15:20, Kashyap Chamarthy wrote:
> +  Recommended to inform the guest that it can disable the Intel TSX
> +  (Transactional Synchronization Extensions) feature; or, if the
> +  processor is vulnerable, use the Intel VERW instruction (a
> +  processor-level instruction that performs checks on memory access) as
> +  a mitigation for the TAA vulnerability.  (For details, refer to this
> +  `Intel's deep-dive into
> +  MDS <https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-microarchitectural-data-sampling>`_.)

... refer to Intel's `deep dive into MDS <...>`_.

(I don't know what the trailing underscore is for.  I reaffirm my
definition of rST as the Perl of markup formats).

> +
> +  Expose this to the guest OS if and only if: (a) the host has TSX
> +  enabled; *and* (b) the guest has ``rtm`` CPU flag enabled.
> +
> +  By disabling TSX, KVM-based guests can avoid paying the price of
> +  mitigting TSX-based attacks.

"mitigating"

Paolo
Peter Maydell Feb. 20, 2020, 3:45 p.m. UTC | #2 
On Thu, 20 Feb 2020 at 14:52, Paolo Bonzini <pbonzini@redhat.com> wrote:
> ... refer to Intel's `deep dive into MDS <...>`_.
>
> (I don't know what the trailing underscore is for.

It's because the external-hyperlink syntax is a complication
of the simpler format for within-document references. Inside
a document, you can have a simple link like this:

  This is a link to the target_ defined below.

  .. _target:

  This is where the link target defined above goes to.

So trailing underscore is for words that go to somewhere else,
and leading underscore for words that come from somewhere else.

Syntax complication 1 is that instead of word_ you can
say `some phrase with spaces`_ if you want the link to
span more than one word. (The docutils spec calls these
"phrase-references").

Syntax complication 2 is that instead of having to define
the target of an external URL separately from the place
you wanted to refer to it, like this:

  .. _target: http://somewhere-else.org/

you can directly embed it inside a phrase-reference:

  Go to `somewhere external <http://somewhere-else.org/>`_

which is more convenient if you only wanted to use the URL once.
But the _ is still there because it's still the markup that
indicates "this is going be a link to go somewhere".

> I reaffirm my definition of rST as the Perl of markup formats).

Not going to argue with that :-)  But like Perl, there's
usually some kind of a rationale lurking under the surface.

thanks
-- PMM
diff mbox series

Patch

diff --git a/docs/system/qemu-cpu-models.rst b/docs/system/qemu-cpu-models.rst
index a189d6a9da..946e90e1dc 100644
--- a/docs/system/qemu-cpu-models.rst
+++ b/docs/system/qemu-cpu-models.rst
@@ -61,15 +61,24 @@  mixture of host CPU models between machines, if live migration
 compatibility is required, use the newest CPU model that is compatible
 across all desired hosts.
 
+* Intel Xeon Processor (Cascade Lake, 2019), with "stepping" levels 6 or
+  7 only.  (The Cascade Lake Xeon processor with *stepping 5 is
+  vulnerable to MDS variants*.)
+
+  * ``Cascadelake-Server``
+  * ``Cascadelake-Server-noTSX``
+
 * Intel Xeon Processor (Skylake, 2016)
 
   * ``Skylake-Server``
   * ``Skylake-Server-IBRS``
+  * ``Skylake-Server-IBRS-noTSX``
 
 * Intel Core Processor (Skylake, 2015)
 
   * ``Skylake-Client``
   * ``Skylake-Client-IBRS``
+  * ``Skylake-Client-noTSX-IBRS}``
 
 * Intel Core Processor (Broadwell, 2014)
 
@@ -182,6 +191,54 @@  features are included if using "Host passthrough" or "Host model".
   Requires the host CPU microcode to support this feature before it
   can be used for guest CPUs.
 
+``mds-no``
+  Recommended to inform the guest OS that the host is *not* vulnerable
+  to any of the MDS variants ([MFBDS] CVE-2018-12130, [MLPDS]
+  CVE-2018-12127, [MSBDS] CVE-2018-12126).
+
+  This is an MSR (Model-Specific Register) feature rather than a CPUID feature,
+  so it will not appear in the Linux ``/proc/cpuinfo`` in the host or
+  guest.  Instead, the host kernel uses it to populate the MDS
+  vulnerability file in ``sysfs``.
+
+  So it should only be enabled for VMs if the host reports @code{Not
+  affected} in the ``/sys/devices/system/cpu/vulnerabilities/mds`` file.
+
+``taa-no``
+  Recommended to inform that the guest that the host is ``not``
+  vulnerable to CVE-2019-11135, TSX Asynchronous Abort (TAA).
+
+  This too is an MSR feature, so it does not show up in the Linux
+  ``/proc/cpuinfo`` in the host or guest.
+
+  It should only be enabled for VMs if the host reports ``Not affected``
+  in the ``/sys/devices/system/cpu/vulnerabilities/tsx_async_abort``
+  file.
+
+``tsx-ctrl``
+  Recommended to inform the guest that it can disable the Intel TSX
+  (Transactional Synchronization Extensions) feature; or, if the
+  processor is vulnerable, use the Intel VERW instruction (a
+  processor-level instruction that performs checks on memory access) as
+  a mitigation for the TAA vulnerability.  (For details, refer to this
+  `Intel's deep-dive into
+  MDS <https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-microarchitectural-data-sampling>`_.)
+
+  Expose this to the guest OS if and only if: (a) the host has TSX
+  enabled; *and* (b) the guest has ``rtm`` CPU flag enabled.
+
+  By disabling TSX, KVM-based guests can avoid paying the price of
+  mitigting TSX-based attacks.
+
+  Note that ``tsx-ctrl`` too is an MSR feature, so it does not show
+  up in the Linux ``/proc/cpuinfo`` in the host or guest.
+
+  To validate that Intel TSX is indeed disabled for the guest, there are
+  two ways: (a) check for the *absence* of ``rtm`` in the guest's
+  ``/proc/cpuinfo``; or (b) the
+  ``/sys/devices/system/cpu/vulnerabilities/tsx_async_abort`` file in
+  the guest should report ``Mitigation: TSX disabled``.
+
 
 Preferred CPU models for AMD x86 hosts
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~