| Message ID | 20200121184940.26520-1-kchamart@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] qemu-cpu-models: Document -noTSX, mds-no, taa-no, and tsx-ctrl | expand |
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 > >
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 > >
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. [...]
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
- 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(-)