[PATCH v2] qemu-cpu-models: Document -noTSX, mds-no, taa-no, and tsx-ctrl

[PATCH v2] qemu-cpu-models: Document -noTSX, mds-no, taa-no, and tsx-ctrl

[Kashyap Chamarthy]

- Add the '-noTSX' variants for CascadeLake and SkyLake.

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

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

  (1) The 'mds-no' 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.

      [+] 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>
---
v2:
 - Address feedback from DanPB
 - Add sections on 'taa-no' and 'tsx-ctrl' (appreciate a closer look on
   the latter).

Question: How can a user validate that TSX is indeed disabled for the
          guest?
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
---
 docs/qemu-cpu-models.texi | 53 ++++++++++++++++++++++++++++++++++++++-
 1 file changed, 52 insertions(+), 1 deletion(-)

diff --git a/docs/qemu-cpu-models.texi b/docs/qemu-cpu-models.texi
index f88a1def0d042cc25213259172a648f0a9c514dc..4b608513f2ba54efc91300ee3fe4b6a6ebe02cef 100644
--- a/docs/qemu-cpu-models.texi
+++ b/docs/qemu-cpu-models.texi
@@ -72,14 +72,25 @@ between machines, if live migration compatibility is required, use the newest
 CPU model that is compatible across all desired hosts.
 
 @table @option
+
+@item @code{Cascadelake-Server}
+@item @code{Cascadelake-Server-noTSX}
+
+Intel Xeon Processor (Cascade Lake, 2019), with "stepping" levels
+6 or 7 only.  (The Cascade Lake Xeon processor with @b{stepping 5 is
+vulnerable to MDS variants}.)
+
+
 @item @code{Skylake-Server}
 @item @code{Skylake-Server-IBRS}
+@item @code{Skylake-Server-noTSX-IBRS}
 
 Intel Xeon Processor (Skylake, 2016)
 
 
 @item @code{Skylake-Client}
 @item @code{Skylake-Client-IBRS}
+@item @code{Skylake-Client-noTSX-IBRS}
 
 Intel Core Processor (Skylake, 2015)
 
@@ -214,9 +225,49 @@ Must be explicitly turned on for all Intel CPU models.
 
 Requires the host CPU microcode to support this feature before it
 can be used for guest CPUs.
+
+@item @code{mds-no}
+
+Recommended to inform the guest OS that the host is @i{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 @code{/proc/cpuinfo} in the
+host or guest.  Instead, the host kernel uses it to populate the MDS
+vulnerability file in @code{sysfs}.
+
+So it should only be enabled for VMs if the host reports @code{Not
+affected} in the @code{/sys/devices/system/cpu/vulnerabilities/mds}
+file.
+
+@item @code{taa-no}
+
+Recommended to inform that the guest that the host is @i{not} vulnerable
+to CVE-2019-11135, TSX Asyncrnous Abort (TAA).
+
+This too is an MSR feature, so it does not show up in the Linux
+@code{/proc/cpuinfo} in the host or guest.
+
+It should only be enabled for VMs if the host reports @code{Not
+affected} in the
+@code{/sys/devices/system/cpu/vulnerabilities/tsx_async_abort} file.
+
+@item @code{tsx-ctrl}
+
+Recommended to inform the guest to @i{disable} the Intel TSX
+(Transactional Synchronization Extensions) feature.  Expose this to the
+guest OS if and only if: (a) the host has TSX enabled; and (b) the guest
+has @code{rtm} CPU flag enabled.
+
+By disabling TSX, KVM-based guests can avoid paying the price of
+mitigting TSX-based attacks.
+
+Note that too is an MSR feature, so it does not show up in the Linux
+@code{/proc/cpuinfo} in the host or guest.
+
 @end table
 
-
 @node preferred_cpu_models_amd_x86
 @subsubsection Preferred CPU models for AMD x86 hosts
 
-- 
2.21.0

Re: [PATCH v2] qemu-cpu-models: Document -noTSX, mds-no, taa-no, and tsx-ctrl

[Kashyap Chamarthy]

On Tue, Jan 21, 2020 at 07:49:39PM +0100, Kashyap Chamarthy wrote:

[...]

> +@item @code{taa-no}
> +
> +Recommended to inform that the guest that the host is @i{not} vulnerable
> +to CVE-2019-11135, TSX Asyncrnous Abort (TAA).
> +
> +This too is an MSR feature, so it does not show up in the Linux
> +@code{/proc/cpuinfo} in the host or guest.
> +
> +It should only be enabled for VMs if the host reports @code{Not
> +affected} in the
> +@code{/sys/devices/system/cpu/vulnerabilities/tsx_async_abort} file.
> +
> +@item @code{tsx-ctrl}
> +
> +Recommended to inform the guest to @i{disable} the Intel TSX
> +(Transactional Synchronization Extensions) feature.  Expose this to the
> +guest OS if and only if: (a) the host has TSX enabled; and (b) the guest
> +has @code{rtm} CPU flag enabled.
> +
> +By disabling TSX, KVM-based guests can avoid paying the price of
> +mitigting TSX-based attacks.
> +
> +Note that too is an MSR feature, 

"Note that too" --> "Note that this too"

(Will wait for other feedback.  If there no need to respin, maybe the
pull-req submitter can do the touch-up.)

> so it does not show up in the Linux
> +@code{/proc/cpuinfo} in the host or guest.
> +
>  @end table
>  
> -
>  @node preferred_cpu_models_amd_x86
>  @subsubsection Preferred CPU models for AMD x86 hosts
>  
> -- 
> 2.21.0
> 
> 

-- 
/kashyap

Re: [PATCH v2] qemu-cpu-models: Document -noTSX, mds-no, taa-no, and tsx-ctrl

[Paolo Bonzini]

On 21/01/20 19:49, Kashyap Chamarthy wrote:
> Question: How can a user validate that TSX is indeed disabled for the
>           guest?

Look for rtm in /proc/cpuinfo, or look at the TAA entry in the sysfs
vulnerabilities directory.

> +@item @code{mds-no}
> +
> +Recommended to inform the guest OS that the host is @i{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 @code{/proc/cpuinfo} in the
> +host or guest.  Instead, the host kernel uses it to populate the MDS
> +vulnerability file in @code{sysfs}.
> +
> +So it should only be enabled for VMs if the host reports @code{Not
> +affected} in the @code{/sys/devices/system/cpu/vulnerabilities/mds}
> +file.
> +
> +@item @code{taa-no}
> +
> +Recommended to inform that the guest that the host is @i{not} vulnerable
> +to CVE-2019-11135, TSX Asyncrnous Abort (TAA).

Asynchronous

> +
> +This too is an MSR feature, so it does not show up in the Linux
> +@code{/proc/cpuinfo} in the host or guest.
> +
> +It should only be enabled for VMs if the host reports @code{Not
> +affected} in the
> +@code{/sys/devices/system/cpu/vulnerabilities/tsx_async_abort} file.
> +
> +@item @code{tsx-ctrl}
> +
> +Recommended to inform the guest to @i{disable} the Intel TSX
> +(Transactional Synchronization Extensions) feature.

Not "to disable" but rather:

Recommended to inform the guest that it can disable the Intel TSX
feature or (if vulnerable) use the VERW instruction as a mitigation for
the TAA vulnerability.

Paolo

> Expose this to the
> +guest OS if and only if: (a) the host has TSX enabled; and (b) the guest
> +has @code{rtm} CPU flag enabled.
> +
> +By disabling TSX, KVM-based guests can avoid paying the price of
> +mitigting TSX-based attacks.
> +
> +Note that too is an MSR feature, so it does not show up in the Linux
> +@code{/proc/cpuinfo} in the host or guest.
> +
>  @end table
>  
> -
>  @node preferred_cpu_models_amd_x86
>  @subsubsection Preferred CPU models for AMD x86 hosts
>  
> 

Re: [PATCH v2] qemu-cpu-models: Document -noTSX, mds-no, taa-no, and tsx-ctrl

[Kashyap Chamarthy]

On Wed, Jan 22, 2020 at 06:20:51PM +0100, Paolo Bonzini wrote:
> On 21/01/20 19:49, Kashyap Chamarthy wrote:
> > Question: How can a user validate that TSX is indeed disabled for the
> >           guest?
> 
> Look for rtm in /proc/cpuinfo, or look at the TAA entry in the sysfs
> vulnerabilities directory.

Noted.

[...]

> > +@item @code{taa-no}
> > +
> > +Recommended to inform that the guest that the host is @i{not} vulnerable
> > +to CVE-2019-11135, TSX Asyncrnous Abort (TAA).
> 
> Asynchronous

Will fix.

[...]

> > +@item @code{tsx-ctrl}
> > +
> > +Recommended to inform the guest to @i{disable} the Intel TSX
> > +(Transactional Synchronization Extensions) feature.
> 
> Not "to disable" but rather:
> 
> Recommended to inform the guest that it can disable the Intel TSX
> feature or (if vulnerable) use the VERW instruction as a mitigation for
> the TAA vulnerability.

Thanks.  I'll make that last bit to:

    ... use the Intel 'VERW' instruction (a processor-level instruction
    that performs checks on memory access) as a mitigation for the
    TAA vulnerability.

Hope that's accurate-but-vague-enough description of 'VERW'.  (I
realize, as Dave Gilbert said on IRC, the actual description of VERW is
besides the point, as Intel reused that to do something else in addition
to its original purpose).

I just wanted to note a small, high-level blurb on _what_ VERW is,
because I feel awkward leaving such words like that in the air in a
user-facing doc.

[...]

-- 
/kashyap