docs: outline some guidelines for security classification
Beyond the overall virt/non-virt use case classification, there are a number of scenarios which we have decided will not be treated as security issues. Start to document some of these to give consistency in our treatment of incoming disclosures. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Mauro Matteo Cascella <mcascell@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Daniel P. Berrangé committed
Jul 7, 2026 at 11:54 UTC
64d0d2efdd2822c827aa7cd276e15c7cefaccb95
1 file changed
+63
docs/system/security.rst
+63
@@ -75,6 +75,69 @@ Bugs affecting the non-virtualization use case are not considered security
75
bugs at this time. Users with non-virtualization use cases must not rely on
76
QEMU to provide guest isolation or any security guarantees.
77
78
+Security boundary scope
79
+'''''''''''''''''''''''
80
+
81
+Even where a flaw affects the virtualization use case described above,
82
+not all scenarios will be considered in scope. The following guidelines
83
+are used to evaluate whether to apply the full security process, or treat
84
+an issue as a normal bug.
85
+
86
+* **assert** / **abort**. If triggering the code path requires kernel
87
+ privileges (or root account access) in the guest, asserts/aborts in
88
+ QEMU are a self inflicted denial of service. These will **not** be
89
+ treated as security flaws, at most hardening bugs. If triggering the
90
+ code path can be done by an unprivileged guest OS account, this
91
+ **may** justify handling as a security bug.
92
+
93
+* **vhost-user/vfio-user backends**. The backend processes have
94
+ shared memory regions co-mapped with the QEMU process. The intent
95
+ of the process separation is operational resilience & flexibility
96
+ and allowing for independent software suppliers. There is not
97
+ considered to be security boundary between QEMU and the vhost-user
98
+ & vfio-user backends. Thus flaws in the backends which can cause
99
+ crashes / undesirable behaviour in QEMU will **not** be treated as
100
+ security flaws, but should be fixed as hardening bugs.
101
+
102
+* **memory allocation bounds**. There are many ways in which a QEMU
103
+ process can legitimately consume an amount of memory that is
104
+ significantly larger than the assigned guest RAM. QEMU's worst
105
+ case memory usage should be considered effectively unbounded. As
106
+ such the QEMU deployment on the host should account for the
107
+ possibility of large memory peaks and apply countermeasures to
108
+ provide continuity of host operations. It is typical for the Linux
109
+ OOM killer to reap the process triggering host memory overcommit
110
+ in the case of exccessive usage, offering a degree of protection.
111
+ As such, bugs which can lead to excessive/unbounded memory allocations
112
+ will usually not be classified as security flaws, but should be
113
+ fixed as hardening bugs.
114
+
115
+* **degraded guest behaviour**. There are a set of bugs which can
116
+ lead guest hardware devices to misbehave. For example, a flawed
117
+ virtual IOMMU operation may not offer the guest device isolation
118
+ that would otherwise be expected. If a guest triggered exploit
119
+ requires kernel privileges (or root account access), and leads
120
+ to sub-optimal behaviour of the virtual device this is considered
121
+ a self inflicted service degradation. These will **not** be
122
+ treated as security flaws, at most hardening bugs. If triggering
123
+ the code path can be done by an unprivileged guest OS account,
124
+ this may justify handling as a security bug.
125
+
126
+* **nested virtualization**. The scope for nested virtualization
127
+ is to prevent a level 2 guest from breaking out into a level
128
+ 1 guest. As noted above, a number of scenarios exclude security
129
+ handling for flaws only exploitable by the guest kernel / root
130
+ account with affect the guest's own service/availability. In the
131
+ context of nested virtualization with PCI device assignment, it
132
+ may may be possible for a level 2 guest kernel to trigger flaws
133
+ that affect the level 0 QEMU process. While these bugs should be
134
+ fixed, they will not be triaged as security flaws at this time.
135
+
136
+* **low severity impact**. As a catch all rule, issues which
137
+ are judged to have a "low" severity impact on the system will
138
+ usually not justify handling as security bugs, nor assignment
139
+ of CVEs. They will be fixed as routine bugs when time allows.
140
+
141
Architecture
142
------------
143