| .. 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. |