On Tue, Jul 07, 2026 at 06:50:27PM +0100, Daniel P. Berrangé wrote: > 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 <[email protected]> > Reviewed-by: Cédric Le Goater <[email protected]> > Acked-by: Michael S. Tsirkin <[email protected]> > Reviewed-by: Mauro Matteo Cascella <[email protected]> > Signed-off-by: Daniel P. Berrangé <[email protected]> > --- > 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.
It seems to work kinda unreliably here on my laptop. Likes killing firefox for some reason. Using libvirt ... what am I doing wrong? > + 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.
