[PATCH] docs: outline some guidelines for security classification

[PATCH] docs: outline some guidelines for security classification

[Daniel P. Berrangé]

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.
+
 Architecture
 ------------
 
-- 
2.55.0

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

[Thomas Huth]

On 07/07/2026 12.59, 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 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.
Reviewed-by: Thomas Huth <thuth@redhat.com>

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

[Cédric Le Goater]

On 7/7/26 12:59, 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 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.
> +
>   Architecture
>   ------------
>   

Reviewed-by: Cédric Le Goater <clg@redhat.com>

Thanks,

C.

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

[John Levon]

Thanks for pointing me towards this Cédric.

On Tue, Jul 07, 2026 at 11:59:27AM +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 treatemnt of incoming disclosures.

"treatment"

> +* **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.

We're OK with this for vfio-user.

We don't have this properly documented - and we should - but practically
speaking, right now, the QEMU vfio-user client has at least some level of trust
in the server. It's something we would like to improve at some point, but we
could update this statement at that time.

(Note this is different to the VM itself which fundamentally trusts the server
implementation regardless.)

regards
john

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

[Daniel P. Berrangé]

On Tue, Jul 07, 2026 at 01:35:09PM +0100, John Levon wrote:
> 
> Thanks for pointing me towards this Cédric.
> 
> On Tue, Jul 07, 2026 at 11:59:27AM +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 treatemnt of incoming disclosures.
> 
> "treatment"
> 
> > +* **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.
> 
> We're OK with this for vfio-user.
> 
> We don't have this properly documented - and we should - but practically
> speaking, right now, the QEMU vfio-user client has at least some level of trust
> in the server. It's something we would like to improve at some point, but we
> could update this statement at that time.

Yep, can certainly be tweaked later if we want to bring stuff in-scope
again.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

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

[Marc-André Lureau]

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?

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

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

[Michael S. Tsirkin]

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
> >

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

[Daniel P. Berrangé]

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?

There is a section later about QMP/monitor

  https://www.qemu.org/docs/master/system/security.html#sensitive-configurations

For migration we do need to think of something to explain our approach
more clearly, and indeed document our expectations for configuration
for migration (trusted LAN vs TLS + certs).

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

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

[Mauro Matteo Cascella]

On Tue, Jul 7, 2026 at 12: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.

Should we explicitly call out devices like CXL and NVMe where the
boundary between virtualization and emulation is ambiguous and we've
historically triaged them as hardening (non-security) bugs?

> 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.
> +

Reviewed-by: Mauro Matteo Cascella <mcascell@redhat.com>

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

--
Mauro Matteo Cascella
Red Hat Product Security

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

[Daniel P. Berrangé]

On Tue, Jul 07, 2026 at 06:28:20PM +0200, Mauro Matteo Cascella wrote:
> On Tue, Jul 7, 2026 at 12: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.
> 
> Should we explicitly call out devices like CXL and NVMe where the
> boundary between virtualization and emulation is ambiguous and we've
> historically triaged them as hardening (non-security) bugs?

I've got a separate series from last year to be revived, that
explicitly tags every device with its security status, which
will handle that scenario.


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|