xref: /linux/Documentation/admin-guide/hw-vuln/vmscape.rst (revision 223ba8ee0a3986718c874b66ed24e7f87f6b8124)
1.. SPDX-License-Identifier: GPL-2.0
2
3VMSCAPE
4=======
5
6VMSCAPE is a vulnerability that may allow a guest to influence the branch
7prediction in host userspace. It particularly affects hypervisors like QEMU.
8
9Even if a hypervisor may not have any sensitive data like disk encryption keys,
10guest-userspace may be able to attack the guest-kernel using the hypervisor as
11a confused deputy.
12
13Affected processors
14-------------------
15
16The following CPU families are affected by VMSCAPE:
17
18**Intel processors:**
19  - Skylake generation (Parts without Enhanced-IBRS)
20  - Cascade Lake generation - (Parts affected by ITS guest/host separation)
21  - Alder Lake and newer (Parts affected by BHI)
22
23Note that, BHI affected parts that use BHB clearing software mitigation e.g.
24Icelake are not vulnerable to VMSCAPE.
25
26**AMD processors:**
27  - Zen series (families 0x17, 0x19, 0x1a)
28
29** Hygon processors:**
30 - Family 0x18
31
32Mitigation
33----------
34
35Conditional IBPB
36----------------
37
38Kernel tracks when a CPU has run a potentially malicious guest and issues an
39IBPB before the first exit to userspace after VM-exit. If userspace did not run
40between VM-exit and the next VM-entry, no IBPB is issued.
41
42Note that the existing userspace mitigation against Spectre-v2 is effective in
43protecting the userspace. They are insufficient to protect the userspace VMMs
44from a malicious guest. This is because Spectre-v2 mitigations are applied at
45context switch time, while the userspace VMM can run after a VM-exit without a
46context switch.
47
48Vulnerability enumeration and mitigation is not applied inside a guest. This is
49because nested hypervisors should already be deploying IBPB to isolate
50themselves from nested guests.
51
52SMT considerations
53------------------
54
55When Simultaneous Multi-Threading (SMT) is enabled, hypervisors can be
56vulnerable to cross-thread attacks. For complete protection against VMSCAPE
57attacks in SMT environments, STIBP should be enabled.
58
59The kernel will issue a warning if SMT is enabled without adequate STIBP
60protection. Warning is not issued when:
61
62- SMT is disabled
63- STIBP is enabled system-wide
64- Intel eIBRS is enabled (which implies STIBP protection)
65
66System information and options
67------------------------------
68
69The sysfs file showing VMSCAPE mitigation status is:
70
71  /sys/devices/system/cpu/vulnerabilities/vmscape
72
73The possible values in this file are:
74
75 * 'Not affected':
76
77   The processor is not vulnerable to VMSCAPE attacks.
78
79 * 'Vulnerable':
80
81   The processor is vulnerable and no mitigation has been applied.
82
83 * 'Mitigation: IBPB before exit to userspace':
84
85   Conditional IBPB mitigation is enabled. The kernel tracks when a CPU has
86   run a potentially malicious guest and issues an IBPB before the first
87   exit to userspace after VM-exit.
88
89 * 'Mitigation: IBPB on VMEXIT':
90
91   IBPB is issued on every VM-exit. This occurs when other mitigations like
92   RETBLEED or SRSO are already issuing IBPB on VM-exit.
93
94Mitigation control on the kernel command line
95----------------------------------------------
96
97The mitigation can be controlled via the ``vmscape=`` command line parameter:
98
99 * ``vmscape=off``:
100
101   Disable the VMSCAPE mitigation.
102
103 * ``vmscape=ibpb``:
104
105   Enable conditional IBPB mitigation (default when CONFIG_MITIGATION_VMSCAPE=y).
106
107 * ``vmscape=force``:
108
109   Force vulnerability detection and mitigation even on processors that are
110   not known to be affected.
111