From: Kashyap Chamarthy <kchamart@redhat.com>
To: qemu-devel@nongnu.org
Cc: pbonzini@redhat.com, berrange@redhat.com, ehabkost@redhat.com,
rth@twiddle.net
Subject: Re: [PATCH v3] qemu-cpu-models: Document -noTSX, mds-no, taa-no, and tsx-ctrl
Date: Mon, 10 Feb 2020 15:03:53 +0100 [thread overview]
Message-ID: <20200210140353.GB25927@paraplu> (raw)
In-Reply-To: <20200127121625.27078-1-kchamart@redhat.com>
Ping.
On Mon, Jan 27, 2020 at 01:16:24PM +0100, Kashyap Chamarthy wrote:
> - 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>
> ---
> v3:
> - 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'
> ---
> docs/qemu-cpu-models.texi | 65 ++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 64 insertions(+), 1 deletion(-)
>
> diff --git a/docs/qemu-cpu-models.texi b/docs/qemu-cpu-models.texi
> index f88a1def0d042cc25213259172a648f0a9c514dc..8be3fc34570c5af10557b862c467f5520245a85a 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,61 @@ 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 Asynchronous 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 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
> +@url{https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-microarchitectural-data-sampling,
> +this Intel's deep-dive into MDS}.
> +
> +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 @code{tasx-ctrl} too is an MSR feature, so it does not show up
> +in the Linux @code{/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 @i{absence} of @code{rtm} in the guest's
> +@code{/proc/cpuinfo}; or (b) the
> +@code{/sys/devices/system/cpu/vulnerabilities/tsx_async_abort} file in
> +the guest should report @code{Mitigation: TSX disabled}.
> +
> @end table
>
> -
> @node preferred_cpu_models_amd_x86
> @subsubsection Preferred CPU models for AMD x86 hosts
>
> --
> 2.21.0
>
>
--
/kashyap
next prev parent reply other threads:[~2020-02-10 14:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-27 12:16 [PATCH v3] qemu-cpu-models: Document -noTSX, mds-no, taa-no, and tsx-ctrl Kashyap Chamarthy
2020-02-10 14:03 ` Kashyap Chamarthy [this message]
2020-02-17 14:40 ` Kashyap Chamarthy
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=20200210140353.GB25927@paraplu \
--to=kchamart@redhat.com \
--cc=berrange@redhat.com \
--cc=ehabkost@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.