From 64d0d2efdd2822c827aa7cd276e15c7cefaccb95 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= Date: Tue, 7 Jul 2026 11:54:01 +0100 Subject: [PATCH] docs: outline some guidelines for security classification MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Reviewed-by: Cédric Le Goater Acked-by: Michael S. Tsirkin Reviewed-by: Mauro Matteo Cascella Signed-off-by: Daniel P. Berrangé --- docs/system/security.rst | 63 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) diff --git a/docs/system/security.rst b/docs/system/security.rst index 53992048e6..52bbf0cc7a 100644 --- a/docs/system/security.rst +++ b/docs/system/security.rst @@ -75,6 +75,69 @@ Bugs affecting the non-virtualization use case are not considered security bugs at this time. Users with non-virtualization use cases must not rely on QEMU to provide guest isolation or any security guarantees. +Security boundary scope +''''''''''''''''''''''' + +Even where a flaw affects the virtualization use case described above, +not all scenarios will be considered in scope. The following guidelines +are used to evaluate whether to apply the full security process, or treat +an issue as a normal bug. + +* **assert** / **abort**. If triggering the code path requires kernel + privileges (or root account access) in the guest, asserts/aborts in + QEMU are a self inflicted denial of service. These will **not** be + treated as security flaws, at most hardening bugs. If triggering the + code path can be done by an unprivileged guest OS account, this + **may** justify handling as a security bug. + +* **vhost-user/vfio-user backends**. The backend processes have + shared memory regions co-mapped with the QEMU process. The intent + of the process separation is operational resilience & flexibility + and allowing for independent software suppliers. There is not + considered to be security boundary between QEMU and the vhost-user + & vfio-user backends. Thus flaws in the backends which can cause + crashes / undesirable behaviour in QEMU will **not** be treated as + security flaws, but should be fixed as hardening bugs. + +* **memory allocation bounds**. There are many ways in which a QEMU + process can legitimately consume an amount of memory that is + significantly larger than the assigned guest RAM. QEMU's worst + case memory usage should be considered effectively unbounded. As + such the QEMU deployment on the host should account for the + possibility of large memory peaks and apply countermeasures to + provide continuity of host operations. It is typical for the Linux + OOM killer to reap the process triggering host memory overcommit + in the case of exccessive usage, offering a degree of protection. + As such, bugs which can lead to excessive/unbounded memory allocations + will usually not be classified as security flaws, but should be + fixed as hardening bugs. + +* **degraded guest behaviour**. There are a set of bugs which can + lead guest hardware devices to misbehave. For example, a flawed + virtual IOMMU operation may not offer the guest device isolation + that would otherwise be expected. If a guest triggered exploit + requires kernel privileges (or root account access), and leads + to sub-optimal behaviour of the virtual device this is considered + a self inflicted service degradation. These will **not** be + treated as security flaws, at most hardening bugs. If triggering + the code path can be done by an unprivileged guest OS account, + this may justify handling as a security bug. + +* **nested virtualization**. The scope for nested virtualization + is to prevent a level 2 guest from breaking out into a level + 1 guest. As noted above, a number of scenarios exclude security + handling for flaws only exploitable by the guest kernel / root + account with affect the guest's own service/availability. In the + context of nested virtualization with PCI device assignment, it + may may be possible for a level 2 guest kernel to trigger flaws + that affect the level 0 QEMU process. While these bugs should be + fixed, they will not be triaged as security flaws at this time. + +* **low severity impact**. As a catch all rule, issues which + are judged to have a "low" severity impact on the system will + usually not justify handling as security bugs, nor assignment + of CVEs. They will be fixed as routine bugs when time allows. + Architecture ------------