[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

[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

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

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

[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

[Fabiano Rosas]

Daniel P. Berrangé <berrange@redhat.com> writes:

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

+CC peterx

Hi, I put together a draft so we can discuss, let me know what you
think.

Assumptions:

A) The migration stream is assumed to be secured by TLS on a per-host
basis.

B) For migration streams stored to file, including snapshots, it is
assumed that the storage file is authentic, i.e. the files are owned by
the party performing the live migration and have not been tampered with.

C) The network ports used for migration are expected to be available
only during migration. No long-standing listening destination QEMU
process.

D) The network used for migration is expected to be adequately isolated.

E) The migration source QEMU process is assumed to be secure. Compromise
of the source QEMU process is nonetheless possible but exploiting the
migration process is expected to grant no further privileges.

For security consideration, the following are considered:

OUT OF SCOPE:

1) Abort of destination QEMU process while migration is still in course.
Rationale: the source virtual machine is not affected.

2) Migration failure.
Rationale: eventual failed migrations are part of normal operation.

3) Memory over-allocation issues in the destination QEMU process.
Rationale: the destination host's operating system is expected to
constrain resource usage. Process termination due to OOM falls under
point 1 above.

IN SCOPE:

1) Privilege escalation from the guest operating system into the
destination QEMU process or host.

2) Tampering or exfiltration of migration stream data by a third party
at a lower privilege level than either QEMU processes involved in the
migration.

3) Termination of the source QEMU process by source virtual machine
guest userspace, including by forcing host OS resource constraints to
be reached.

4) Other tampering or exfiltration of data from the source QEMU process
if reached from migration code or migration stream manipulation.

5) Causing source QEMU process to enter a state from which migration is
not possible permanently.

The overall effect of this policy is that only legitimately produced
migration data is considered for security implications, whether that
data is malicious or buggy.

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

[Daniel P. Berrangé]

On Thu, Jul 16, 2026 at 11:08:49AM -0300, Fabiano Rosas wrote:

> Assumptions:
> 
> A) The migration stream is assumed to be secured by TLS on a per-host
> basis.
> 
> B) For migration streams stored to file, including snapshots, it is
> assumed that the storage file is authentic, i.e. the files are owned by
> the party performing the live migration and have not been tampered with.

Can you clarify "the party performing the live migration" ?

Is that referring to the "guest owner" who initiates the migration,
or is that referring to the mgmt app control plane.

The risk I've always been concerned about is the guest owner
tampering with state files, though I'm increasing coming to
the view point that state files must *never* be allowed to be
modified by the guest owner. Mgmt apps must either prevent
that through storage permissions, or detect that by digitally
signing state files that are theoretically writable by guest
owners & validate sig before restore.


> C) The network ports used for migration are expected to be available
> only during migration. No long-standing listening destination QEMU
> process.

I wonder, does that make a difference to our risk ?

If we're concerned about an undesirable app/client conjnectnig to a
open network port, QEMU has that threat no matter how short the time
windows is that the ports are accepting incoming clients.  So I'm
not sure this point helps us.

> D) The network used for migration is expected to be adequately isolated.

Is that intended to be in additional to (A) or instead of (A) ?

If in addition to (A) then I'm wondering what benefits listing
this point brings - what risks are eliminated that TLS does not
already eliminate ?

> E) The migration source QEMU process is assumed to be secure. Compromise
> of the source QEMU process is nonetheless possible but exploiting the
> migration process is expected to grant no further privileges.

This is the tricky assumption.

Cnsider source host as 2 QEMU processes, one of tenant A and
one for tenant B.

If tenant A compromises their QEMU, and can wait until a live
migration for tenant B is initiating, potentially tenant A can
connect to a dest QEMU for tenant B. I would consider that to
be gaining privileges.

With TLS we lack fine grained authentication in common setups
today that rely on x509 certs configured per-host, not per-QEMU.

In current libvirt we're introducing oout of the box support for
TLS PSK, which means live migration sessions will be tied to
individual matched (src,dst) QEMU pairs, so even if tenant A is
compromised they would be able to do a TLS handshake for tenant
B's dst QEMU.

I'd like app mgmt apps to switch to PSK instad of x509 for
live migration, but that'll take along time.

None the less if we can assume the source QEMU is trusted,
then that eliminates a huge class of security vulnerabilities,
turning them all into hardening bugs, so I understand this is
very appealing to declare.

> For security consideration, the following are considered:
> 
> OUT OF SCOPE:
> 
> 1) Abort of destination QEMU process while migration is still in course.
> Rationale: the source virtual machine is not affected.

Ack.

> 
> 2) Migration failure.
> Rationale: eventual failed migrations are part of normal operation.

Ack.
 
> 3) Memory over-allocation issues in the destination QEMU process.
> Rationale: the destination host's operating system is expected to
> constrain resource usage. Process termination due to OOM falls under
> point 1 above.

Ack, that falls under our general exlclusion already too, though
we might finesse the language a bit more.

> IN SCOPE:
> 
> 1) Privilege escalation from the guest operating system into the
> destination QEMU process or host.
> 
> 2) Tampering or exfiltration of migration stream data by a third party
> at a lower privilege level than either QEMU processes involved in the
> migration.
> 
> 3) Termination of the source QEMU process by source virtual machine
> guest userspace, including by forcing host OS resource constraints to
> be reached.
> 
> 4) Other tampering or exfiltration of data from the source QEMU process
> if reached from migration code or migration stream manipulation.
> 
> 5) Causing source QEMU process to enter a state from which migration is
> not possible permanently.
> 
> The overall effect of this policy is that only legitimately produced
> migration data is considered for security implications, whether that
> data is malicious or buggy.

WIth this it seems like the only 2 scenarios where a migration security
flaw can be issued are:

 * Something goes wrong before/during the TLS handshake
 * A bug in source QEMU, somehow allows a guest OS user
   to set magic device data that turns into an exploitable
   VM state record.

Again, certainly appealing, but for the edge case that even with TLS,
we don't have fine grained access control, so we know the source is
a valid QEMU, but we don't know if it is the QEMU we expected.

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

[Peter Xu]

On Thu, Jul 16, 2026 at 11:08:49AM -0300, Fabiano Rosas wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > 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).
> >
> 
> +CC peterx
> 
> Hi, I put together a draft so we can discuss, let me know what you
> think.

Below looks good in general, some trivial comments inline.

> 
> Assumptions:
> 
> A) The migration stream is assumed to be secured by TLS on a per-host
> basis.
> 
> B) For migration streams stored to file, including snapshots, it is
> assumed that the storage file is authentic, i.e. the files are owned by
> the party performing the live migration and have not been tampered with.
> 
> C) The network ports used for migration are expected to be available
> only during migration. No long-standing listening destination QEMU
> process.
> 
> D) The network used for migration is expected to be adequately isolated.
> 
> E) The migration source QEMU process is assumed to be secure. Compromise
> of the source QEMU process is nonetheless possible but exploiting the
> migration process is expected to grant no further privileges.

Yes, having this whole section should help clarify things a lot.

> 
> For security consideration, the following are considered:
> 
> OUT OF SCOPE:
> 
> 1) Abort of destination QEMU process while migration is still in course.
> Rationale: the source virtual machine is not affected.
> 
> 2) Migration failure.
> Rationale: eventual failed migrations are part of normal operation.
> 
> 3) Memory over-allocation issues in the destination QEMU process.
> Rationale: the destination host's operating system is expected to
> constrain resource usage. Process termination due to OOM falls under
> point 1 above.

This whole section is good too.

Though for 3), I'd not say the dest host is expected to constrain resouce
usage.  For example, if there is way to cause over-allocate in a daemon it
should still be treated a real host mem DoS, and we may or may not always
assume the guest processes are protected by memcg or something alike.

However, I still agree with the conclusion: it's out of scope of migration
not because #1, but because dest QEMU process is in the "secure zone" and
it's not a generic daemon, hence ASSUMPTION A)+C)+D).  If the attacker can
reach it and talk to it, something has already been breached.

> 
> IN SCOPE:

It's harder to follow for what are described as IN SCOPE below.. except..

> 
> 1) Privilege escalation from the guest operating system into the
> destination QEMU process or host.
> 
> 2) Tampering or exfiltration of migration stream data by a third party
> at a lower privilege level than either QEMU processes involved in the
> migration.
> 
> 3) Termination of the source QEMU process by source virtual machine
> guest userspace, including by forcing host OS resource constraints to
> be reached.
> 
> 4) Other tampering or exfiltration of data from the source QEMU process
> if reached from migration code or migration stream manipulation.
> 
> 5) Causing source QEMU process to enter a state from which migration is
> not possible permanently.
> 
> The overall effect of this policy is that only legitimately produced
> migration data is considered for security implications, whether that
> data is malicious or buggy.

.. I kind of get what you wanted to say. The only legit way to interact
with migration module that I can think of, is either from guest access
(manipulation of guest device registers etc. iow, malicious drivers),
causing migration misbehave / disfunction, or via host side interfacing
like QMP/HMP causing source host / guest damage, this time memory DoS
could be a bigger problem for sure comparing to a dest QEMU DoS, but this
then also depends on how we want to define the scope for monitors in
general.

I wonder if we can simply above 5 points into something simpler, or skip
for now?  To me, what is out of scope is more valuable to be put into doc,
because I bet 99% if not all of existing "security issues" on migration in
past few months fall into it.. so it saves huge time already for triaging.

-- 
Peter Xu

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

[Fabiano Rosas]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Thu, Jul 16, 2026 at 11:08:49AM -0300, Fabiano Rosas wrote:
>
>> Assumptions:
>> 
>> A) The migration stream is assumed to be secured by TLS on a per-host
>> basis.
>> 
>> B) For migration streams stored to file, including snapshots, it is
>> assumed that the storage file is authentic, i.e. the files are owned by
>> the party performing the live migration and have not been tampered with.
>
> Can you clarify "the party performing the live migration" ?
>
> Is that referring to the "guest owner" who initiates the migration,
> or is that referring to the mgmt app control plane.
>

I was thinking that the entity issuing qmp_migrate/loadvm should
guarantee the integrity of the file up to that moment and while QEMU is
reading it.

I would say when there's a management application, that is the entity
we're talking about, but could very well be an end-user issuing commands
to QEMU directly.

> The risk I've always been concerned about is the guest owner
> tampering with state files, though I'm increasing coming to
> the view point that state files must *never* be allowed to be
> modified by the guest owner. Mgmt apps must either prevent
> that through storage permissions, or detect that by digitally
> signing state files that are theoretically writable by guest
> owners & validate sig before restore.
>

I think it makes sense for the management app to impose such a
constraint. I'm not so sure about QEMU expecting that it does,
though. Some apps might have a different opinion and the users are
probably not going to like losing access.

Doesn't the guest owner already have control over what goes in the
migration stream in the first place?

>
>> C) The network ports used for migration are expected to be available
>> only during migration. No long-standing listening destination QEMU
>> process.
>
> I wonder, does that make a difference to our risk ?
>
> If we're concerned about an undesirable app/client conjnectnig to a
> open network port, QEMU has that threat no matter how short the time
> windows is that the ports are accepting incoming clients.  So I'm
> not sure this point helps us.
>

I'm more worried about an unexpected migration. An incoming vm will just
take whatever is given to it. If there is a (legitimate) migration
happening in a short window of time, attempts to hijack that destination
machine would cause a migration failure and be detectable.

Now I'm also thinking of an eavesdropper tagging along in some multifd
channel, if that's even possible.

>> D) The network used for migration is expected to be adequately isolated.
>
> Is that intended to be in additional to (A) or instead of (A) ?
>
> If in addition to (A) then I'm wondering what benefits listing
> this point brings - what risks are eliminated that TLS does not
> already eliminate ?
>

In addition. Then maybe you're right that there's no additional benefit,
I can't think of a scenario. However it's common practice for admins to
not use TLS and rely on network isolation. I don't want to make it seem
that TLS is mandatory. As Peter pointed out, it's not a default
configuration.

>> E) The migration source QEMU process is assumed to be secure. Compromise
>> of the source QEMU process is nonetheless possible but exploiting the
>> migration process is expected to grant no further privileges.
>
> This is the tricky assumption.
>
> Cnsider source host as 2 QEMU processes, one of tenant A and
> one for tenant B.
>
> If tenant A compromises their QEMU, and can wait until a live
> migration for tenant B is initiating, potentially tenant A can
> connect to a dest QEMU for tenant B. I would consider that to
> be gaining privileges.
>

I thought of that, but I can't understand how "dest QEMU for tenant B"
isn't just "dest QEMU for tenant A that has now took over". If none of
the stream from source B is reaching dest B, then that's harmless.

Unless some scenario like what I mentioned above with multifd is in
play.

Now, can tenant A bug their QEMU to the point that it receives a
migration from tenant B? Then that falls into IN SCOPE point 2 below.

Maybe we need to have a parentheses for the multi-tenant scenario.

I think we need some guideline to help triaging the infinite
hypotheticals of "what if source QEMU magically puts X one the stream?".

> With TLS we lack fine grained authentication in common setups
> today that rely on x509 certs configured per-host, not per-QEMU.
>
> In current libvirt we're introducing oout of the box support for
> TLS PSK, which means live migration sessions will be tied to
> individual matched (src,dst) QEMU pairs, so even if tenant A is
> compromised they would be able to do a TLS handshake for tenant
> B's dst QEMU.
>

ITYM "wouldn't be able".

> I'd like app mgmt apps to switch to PSK instad of x509 for
> live migration, but that'll take along time.
>

Is TLS PSK a reasonable setup to expect and to include in this policy?

> None the less if we can assume the source QEMU is trusted,
> then that eliminates a huge class of security vulnerabilities,
> turning them all into hardening bugs, so I understand this is
> very appealing to declare.
>

It is, I'm keen to do it. I expect a compromised QEMU to be either a
very rare situation or to fall into the "you have bigger problems"
area. But if we decide it's an important vector of attack, so be it.

>> For security consideration, the following are considered:
>> 
>> OUT OF SCOPE:
>> 
>> 1) Abort of destination QEMU process while migration is still in course.
>> Rationale: the source virtual machine is not affected.
>
> Ack.
>
>> 
>> 2) Migration failure.
>> Rationale: eventual failed migrations are part of normal operation.
>
> Ack.
>  
>> 3) Memory over-allocation issues in the destination QEMU process.
>> Rationale: the destination host's operating system is expected to
>> constrain resource usage. Process termination due to OOM falls under
>> point 1 above.
>
> Ack, that falls under our general exlclusion already too, though
> we might finesse the language a bit more.
>
>> IN SCOPE:
>> 
>> 1) Privilege escalation from the guest operating system into the
>> destination QEMU process or host.
>> 
>> 2) Tampering or exfiltration of migration stream data by a third party
>> at a lower privilege level than either QEMU processes involved in the
>> migration.
>> 
>> 3) Termination of the source QEMU process by source virtual machine
>> guest userspace, including by forcing host OS resource constraints to
>> be reached.
>> 
>> 4) Other tampering or exfiltration of data from the source QEMU process
>> if reached from migration code or migration stream manipulation.
>> 
>> 5) Causing source QEMU process to enter a state from which migration is
>> not possible permanently.
>> 
>> The overall effect of this policy is that only legitimately produced
>> migration data is considered for security implications, whether that
>> data is malicious or buggy.
>
> WIth this it seems like the only 2 scenarios where a migration security
> flaw can be issued are:
>
>  * Something goes wrong before/during the TLS handshake
>  * A bug in source QEMU, somehow allows a guest OS user
>    to set magic device data that turns into an exploitable
>    VM state record.
>

We don't need a bug in source QEMU, the magic data could be within
accepted parameters.

> Again, certainly appealing, but for the edge case that even with TLS,
> we don't have fine grained access control, so we know the source is
> a valid QEMU, but we don't know if it is the QEMU we expected.
>
> With regards,
> Daniel

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

[Fabiano Rosas]

Peter Xu <peterx@redhat.com> writes:

> On Thu, Jul 16, 2026 at 11:08:49AM -0300, Fabiano Rosas wrote:
>> Daniel P. Berrangé <berrange@redhat.com> writes:
>> 
>> > 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).
>> >
>> 
>> +CC peterx
>> 
>> Hi, I put together a draft so we can discuss, let me know what you
>> think.
>
> Below looks good in general, some trivial comments inline.
>
>> 
>> Assumptions:
>> 
>> A) The migration stream is assumed to be secured by TLS on a per-host
>> basis.
>> 
>> B) For migration streams stored to file, including snapshots, it is
>> assumed that the storage file is authentic, i.e. the files are owned by
>> the party performing the live migration and have not been tampered with.
>> 
>> C) The network ports used for migration are expected to be available
>> only during migration. No long-standing listening destination QEMU
>> process.
>> 
>> D) The network used for migration is expected to be adequately isolated.
>> 
>> E) The migration source QEMU process is assumed to be secure. Compromise
>> of the source QEMU process is nonetheless possible but exploiting the
>> migration process is expected to grant no further privileges.
>
> Yes, having this whole section should help clarify things a lot.
>
>> 
>> For security consideration, the following are considered:
>> 
>> OUT OF SCOPE:
>> 
>> 1) Abort of destination QEMU process while migration is still in course.
>> Rationale: the source virtual machine is not affected.
>> 
>> 2) Migration failure.
>> Rationale: eventual failed migrations are part of normal operation.
>> 
>> 3) Memory over-allocation issues in the destination QEMU process.
>> Rationale: the destination host's operating system is expected to
>> constrain resource usage. Process termination due to OOM falls under
>> point 1 above.
>
> This whole section is good too.
>
> Though for 3), I'd not say the dest host is expected to constrain resouce
> usage.  For example, if there is way to cause over-allocate in a daemon it
> should still be treated a real host mem DoS, and we may or may not always
> assume the guest processes are protected by memcg or something alike.
>
> However, I still agree with the conclusion: it's out of scope of migration
> not because #1, but because dest QEMU process is in the "secure zone" and
> it's not a generic daemon, hence ASSUMPTION A)+C)+D).  If the attacker can
> reach it and talk to it, something has already been breached.
>

Ok, let's try to tweak this part.

>> 
>> IN SCOPE:
>
> It's harder to follow for what are described as IN SCOPE below.. except..
>
>> 
>> 1) Privilege escalation from the guest operating system into the
>> destination QEMU process or host.
>> 
>> 2) Tampering or exfiltration of migration stream data by a third party
>> at a lower privilege level than either QEMU processes involved in the
>> migration.
>> 
>> 3) Termination of the source QEMU process by source virtual machine
>> guest userspace, including by forcing host OS resource constraints to
>> be reached.
>> 
>> 4) Other tampering or exfiltration of data from the source QEMU process
>> if reached from migration code or migration stream manipulation.
>> 
>> 5) Causing source QEMU process to enter a state from which migration is
>> not possible permanently.
>> 
>> The overall effect of this policy is that only legitimately produced
>> migration data is considered for security implications, whether that
>> data is malicious or buggy.
>
> .. I kind of get what you wanted to say. The only legit way to interact
> with migration module that I can think of, is either from guest access
> (manipulation of guest device registers etc. iow, malicious drivers),
> causing migration misbehave / disfunction, or via host side interfacing
> like QMP/HMP causing source host / guest damage, this time memory DoS
> could be a bigger problem for sure comparing to a dest QEMU DoS, but this
> then also depends on how we want to define the scope for monitors in
> general.
>
> I wonder if we can simply above 5 points into something simpler, or skip
> for now?  To me, what is out of scope is more valuable to be put into doc,
> because I bet 99% if not all of existing "security issues" on migration in
> past few months fall into it.. so it saves huge time already for triaging.

I want to reduce the guesswork both when reporting issues and when
triaging. People tend to sit around and imagine infinite scenarios, it's
not productive.

This section is so we can point at it and ask for some indication of any
of the points above. Otherwise we'll get the random bug report saying
that weird behavior was achieved, therefore CVE. These are the
situations I could think of that would obviously be worthy of further
consideration.

Could you expand on why you think this is not worth having? I don't
think I understand it.

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

[Peter Xu]

On Thu, Jul 16, 2026 at 03:51:31PM -0300, Fabiano Rosas wrote:
> > I wonder if we can simply above 5 points into something simpler, or skip
> > for now?  To me, what is out of scope is more valuable to be put into doc,
> > because I bet 99% if not all of existing "security issues" on migration in
> > past few months fall into it.. so it saves huge time already for triaging.
> 
> I want to reduce the guesswork both when reporting issues and when
> triaging. People tend to sit around and imagine infinite scenarios, it's
> not productive.
> 
> This section is so we can point at it and ask for some indication of any
> of the points above. Otherwise we'll get the random bug report saying
> that weird behavior was achieved, therefore CVE. These are the
> situations I could think of that would obviously be worthy of further
> consideration.
> 
> Could you expand on why you think this is not worth having? I don't
> think I understand it.

I didn't expect to point to a bug report into "IN SCOPE" category.  IMHO,
the major use case for the doc is to point a bug report into "OUT OF SCOPE"
category.. then we can easily justify an issue to be not a CVE candidate.

When it is a real security issue, we likely need to evaluate it case by
case, but first it needs to not directly fall int OUT OF SCOPE first.

I think it could be that I hardly have any real experience with a legit
security report versus migration yet, but we have richer experience on
"what we don't think is a security issue, but only a bug" thanks to AI.. so
NOT IN SCOPE is easier to list to me than IN SCOPE ones.

Neither do I have very clear idea after reading the five examples given.

To make it clearer on what I meant, I can start by asking some questions on
the five examples listed IN SCOPE.  You don't need to answer all, or
maybe.. no need to answer any of them, just to show my confusions on
reading the examples (hence the request of simplifications, or removal, at
first version).

> 1) Privilege escalation from the guest operating system into the
> destination QEMU process or host.

Do you mean any form of guest operation to cause privilege escalation?
Obviously, it must be about during a live migration happening, otherwise I
don't see how it is relevant to migration, but then is this only talking
about a postcopy use case (where dest QEMU has vCPU running)?  After all,
precopy migration guest operations all done on source, so if there's any
privilege escalation, it needs to happen on source host first.

Also, I am a bit lost on why this is special for migration.  Such issue can
happen on any host without migration.  It's a bit unclear to me.

> 
> 2) Tampering or exfiltration of migration stream data by a third party
> at a lower privilege level than either QEMU processes involved in the
> migration.

If we have the ASSUMPTION describing migration stream is secure, why do we
worry about third party hijacking migration stream?  Someone already
breached?

> 
> 3) Termination of the source QEMU process by source virtual machine
> guest userspace, including by forcing host OS resource constraints to
> be reached.

This is also not clear on how it correlates to migration, because IIUC this
can also happen without migration.  Maybe it's trying to catch the cases
where it only can be attacked during migration?

What is "guest userspace"?  Is that the userspace of the guest OS?

> 
> 4) Other tampering or exfiltration of data from the source QEMU process
> if reached from migration code or migration stream manipulation.

This is a very generic statement to me, even though I think it's correct..
Say, how stream can be manipulated with TLS encryption?  If it's
manipulated from the guest, is the guest data being tampered on its own or
some other data?

> 
> 5) Causing source QEMU process to enter a state from which migration is
> not possible permanently.

This is a very valid one and clear to understand.  However I don't know if
any of such would really happen, though.  It's easier to happen to me when
e.g. we leaked memory in QMP handlers which may cause DoS rather than
"cannot migrate anymore"..

Also, if it's only the VM itself got affected (say, attacker from guest
within causing its VM not migratable), then the damage it can cause is very
limited too.  I'm not 100% sure I know how severe is such, and whether it's
CVE.

-- 
Peter Xu