diff options
author | Pawan Gupta <pawan.kumar.gupta@linux.intel.com> | 2022-05-19 20:35:15 -0700 |
---|---|---|
committer | Borislav Petkov <bp@suse.de> | 2022-05-21 12:41:35 +0200 |
commit | 027bbb884be006b05d9c577d6401686053aa789e (patch) | |
tree | b60942dd17dc33f97ae5c81cd972b96100283d18 /tools/perf/scripts/python/arm-cs-trace-disasm.py | |
parent | a992b8a4682f119ae035a01b40d4d0665c4a2875 (diff) | |
download | linux-027bbb884be006b05d9c577d6401686053aa789e.tar.gz linux-027bbb884be006b05d9c577d6401686053aa789e.tar.bz2 linux-027bbb884be006b05d9c577d6401686053aa789e.zip |
KVM: x86/speculation: Disable Fill buffer clear within guests
The enumeration of MD_CLEAR in CPUID(EAX=7,ECX=0).EDX{bit 10} is not an
accurate indicator on all CPUs of whether the VERW instruction will
overwrite fill buffers. FB_CLEAR enumeration in
IA32_ARCH_CAPABILITIES{bit 17} covers the case of CPUs that are not
vulnerable to MDS/TAA, indicating that microcode does overwrite fill
buffers.
Guests running in VMM environments may not be aware of all the
capabilities/vulnerabilities of the host CPU. Specifically, a guest may
apply MDS/TAA mitigations when a virtual CPU is enumerated as vulnerable
to MDS/TAA even when the physical CPU is not. On CPUs that enumerate
FB_CLEAR_CTRL the VMM may set FB_CLEAR_DIS to skip overwriting of fill
buffers by the VERW instruction. This is done by setting FB_CLEAR_DIS
during VMENTER and resetting on VMEXIT. For guests that enumerate
FB_CLEAR (explicitly asking for fill buffer clear capability) the VMM
will not use FB_CLEAR_DIS.
Irrespective of guest state, host overwrites CPU buffers before VMENTER
to protect itself from an MMIO capable guest, as part of mitigation for
MMIO Stale Data vulnerabilities.
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Diffstat (limited to 'tools/perf/scripts/python/arm-cs-trace-disasm.py')
0 files changed, 0 insertions, 0 deletions