111 lines
3.3 KiB
ReStructuredText
111 lines
3.3 KiB
ReStructuredText
.. SPDX-License-Identifier: GPL-2.0
|
|
|
|
VMSCAPE
|
|
=======
|
|
|
|
VMSCAPE is a vulnerability that may allow a guest to influence the branch
|
|
prediction in host userspace. It particularly affects hypervisors like QEMU.
|
|
|
|
Even if a hypervisor may not have any sensitive data like disk encryption keys,
|
|
guest-userspace may be able to attack the guest-kernel using the hypervisor as
|
|
a confused deputy.
|
|
|
|
Affected processors
|
|
-------------------
|
|
|
|
The following CPU families are affected by VMSCAPE:
|
|
|
|
**Intel processors:**
|
|
- Skylake generation (Parts without Enhanced-IBRS)
|
|
- Cascade Lake generation - (Parts affected by ITS guest/host separation)
|
|
- Alder Lake and newer (Parts affected by BHI)
|
|
|
|
Note that, BHI affected parts that use BHB clearing software mitigation e.g.
|
|
Icelake are not vulnerable to VMSCAPE.
|
|
|
|
**AMD processors:**
|
|
- Zen series (families 0x17, 0x19, 0x1a)
|
|
|
|
** Hygon processors:**
|
|
- Family 0x18
|
|
|
|
Mitigation
|
|
----------
|
|
|
|
Conditional IBPB
|
|
----------------
|
|
|
|
Kernel tracks when a CPU has run a potentially malicious guest and issues an
|
|
IBPB before the first exit to userspace after VM-exit. If userspace did not run
|
|
between VM-exit and the next VM-entry, no IBPB is issued.
|
|
|
|
Note that the existing userspace mitigation against Spectre-v2 is effective in
|
|
protecting the userspace. They are insufficient to protect the userspace VMMs
|
|
from a malicious guest. This is because Spectre-v2 mitigations are applied at
|
|
context switch time, while the userspace VMM can run after a VM-exit without a
|
|
context switch.
|
|
|
|
Vulnerability enumeration and mitigation is not applied inside a guest. This is
|
|
because nested hypervisors should already be deploying IBPB to isolate
|
|
themselves from nested guests.
|
|
|
|
SMT considerations
|
|
------------------
|
|
|
|
When Simultaneous Multi-Threading (SMT) is enabled, hypervisors can be
|
|
vulnerable to cross-thread attacks. For complete protection against VMSCAPE
|
|
attacks in SMT environments, STIBP should be enabled.
|
|
|
|
The kernel will issue a warning if SMT is enabled without adequate STIBP
|
|
protection. Warning is not issued when:
|
|
|
|
- SMT is disabled
|
|
- STIBP is enabled system-wide
|
|
- Intel eIBRS is enabled (which implies STIBP protection)
|
|
|
|
System information and options
|
|
------------------------------
|
|
|
|
The sysfs file showing VMSCAPE mitigation status is:
|
|
|
|
/sys/devices/system/cpu/vulnerabilities/vmscape
|
|
|
|
The possible values in this file are:
|
|
|
|
* 'Not affected':
|
|
|
|
The processor is not vulnerable to VMSCAPE attacks.
|
|
|
|
* 'Vulnerable':
|
|
|
|
The processor is vulnerable and no mitigation has been applied.
|
|
|
|
* 'Mitigation: IBPB before exit to userspace':
|
|
|
|
Conditional IBPB mitigation is enabled. The kernel tracks when a CPU has
|
|
run a potentially malicious guest and issues an IBPB before the first
|
|
exit to userspace after VM-exit.
|
|
|
|
* 'Mitigation: IBPB on VMEXIT':
|
|
|
|
IBPB is issued on every VM-exit. This occurs when other mitigations like
|
|
RETBLEED or SRSO are already issuing IBPB on VM-exit.
|
|
|
|
Mitigation control on the kernel command line
|
|
----------------------------------------------
|
|
|
|
The mitigation can be controlled via the ``vmscape=`` command line parameter:
|
|
|
|
* ``vmscape=off``:
|
|
|
|
Disable the VMSCAPE mitigation.
|
|
|
|
* ``vmscape=ibpb``:
|
|
|
|
Enable conditional IBPB mitigation (default when CONFIG_MITIGATION_VMSCAPE=y).
|
|
|
|
* ``vmscape=force``:
|
|
|
|
Force vulnerability detection and mitigation even on processors that are
|
|
not known to be affected.
|