Re: [PATCH] docs: outline some guidelines for security classification

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Jul 07, 2026 at 04:43:43PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Tue, Jul 7, 2026 at 2:59 PM Daniel P. Berrangé <berrange@redhat.com> 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 treatemnt of incoming disclosures.
> >
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> >
> > Mauro / Michael: please suggest any other rules which we have applied
> > historically on qemu-security disclosures that we should capture here.
> >
> > The vfio-user/vhost-user addition is a new one based on discussions
> > in some GitLab issues today/yesterday
> >
> >  docs/system/security.rst | 63 ++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 63 insertions(+)
> >
> > diff --git a/docs/system/security.rst b/docs/system/security.rst
> > index 53992048e6..fbbca50f95 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 triggernig
> > +  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.
> 
> Should we have a section about management-plane protocols? (migration,
> QMP, monitor), since they already require trusted network access?


Yes please. But this can be a patch on top.  For this one:

Acked-by: Michael S. Tsirkin <mst@redhat.com>


> > +
> >  Architecture
> >  ------------
> >
> > --
> > 2.55.0
> >