[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

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

[Michael S. Tsirkin]

On Tue, Jul 07, 2026 at 11:59:27AM +0100, Daniel P. Berrangé wrote:
> +* **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.

This really is a bug we need to fix at some point.

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


Well it does not look like existing management stacks do much of this,
perhaps because when we say qemu memory is unbounded
the result is you can't limit memory using cgroups without risk of
qemu dying on oom.


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

Yes but what degree?
At least on my box, it seems to kill firefox at about 50% of time (

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

should we classify guest driven memory leaks and guest driven
memory spikes differently?


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

[Fabiano Rosas]

Peter Xu <peterx@redhat.com> writes:

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

I see.

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

Thanks, let's see if I can defend myself! =)

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

I mean when the guest OS does some trickery that gets propagated to the
destination machine via migration and the person controlling that guest
gets privileges on the QEMU process on the destination. Injecting a
payload of some sort, or setting up a device to allow later
exploitation.

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

We assume the stream is secure, but there could still be a bug in the
migration code that allows a thirdy party to read the stream. As for
"tampering", you're right that's probably already covered by the
assumptions we made earlier.

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

Yes, say the userspace inside the guest does something that causes the
migration code to crash when qmp_migrate is issued, for instance. I'm
not saying it's a simple thing to happen, just that IF it happens, then
we have already reasoned about it and agreed that it has the potential
to become a CVE.

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

Yes, assuming the OS itself already has ways to shoot itself in the foot
by tampering with devices. But the userspace is in another layer, it
could attempt to do bad things to the 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?
>

Right, this is a catchall meaning: even with all of the above, if
someone finds a way to do this, the previous points do not invalidate
this find.

I guess I wrote all of these with a sense of providing some assurance
that even though we'll possibly be rejecting various bugs as
non-security related, there are still clear situations where there's a
security implication and we're aware of it.

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

I don't think it matters if it would happen. If it ever does, we think
it's bad enough that it will be considered for a CVE. "Considered", as
opposed to just filing it as a normal bug. But the analysis could still
result in nothing and we'd treat it as just a bug anyway.

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

What I'm talking about in this particular point is about putting an
admin in a situation where they can only resort to shutting down the
virtual machine. This is a counterpart to the "failed migrations are
normal" assumption up above; failed migrations can be easily worked
around, but permanent failure cannot.

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

Fair point, maybe it's not super relevant indeed. Note I'm not trying to
say that these items will become CVEs, just that if someone can put an
argument that they can happen, then it's something we'll gladly look
into.

---

See if my answers clarify the situation a bit. It's ok if you still want
to remove the text after reading them. What's more important is that we
hash these things out so we're all in the same page.

Thanks for taking the time to write down your thoughts.

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

[Peter Xu]

On Thu, Jul 16, 2026 at 09:21:53PM -0300, Fabiano Rosas wrote:
> Peter Xu <peterx@redhat.com> writes:
> 
> > 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.
> >
> 
> I see.
> 
> > 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).
> >
> 
> Thanks, let's see if I can defend myself! =)

When we're on the same side, there isn't much to "defend"! :)

> 
> >> 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.
> >
> 
> I mean when the guest OS does some trickery that gets propagated to the
> destination machine via migration and the person controlling that guest
> gets privileges on the QEMU process on the destination. Injecting a
> payload of some sort, or setting up a device to allow later
> exploitation.

To me, it's more likely some exploit will work even without migration, than
some exploit only be enabled only after a migration. But I understand now.
Maybe some more description would be nice?

For example, "privilege escalation that can only be enabled by a migration
process (successful or not)", which IMO it doesn't always need to be on the
dest too, if a failed migration can also trigger an exploit.

I think your wording in English is normally better than mine, though..

> 
> >> 
> >> 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?
> >
> 
> We assume the stream is secure, but there could still be a bug in the
> migration code that allows a thirdy party to read the stream. As for
> "tampering", you're right that's probably already covered by the
> assumptions we made earlier.

I see.  Can it be put in another (hopefully simpler) way? Like "Exploits
that can cause misfunction / disability of migration channel encryptions".

> 
> >> 
> >> 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?
> >
> 
> Yes, say the userspace inside the guest does something that causes the
> migration code to crash when qmp_migrate is issued, for instance. I'm
> not saying it's a simple thing to happen, just that IF it happens, then
> we have already reasoned about it and agreed that it has the potential
> to become a CVE.

If any guest behavior can either crash QEMU or causing monitor commands to
further crash QEMU, then I think it deserves a CVE.

But then here it's about when migration is involved.  It's again a niche
context to think about IMHO, but yes I get what you mean now.

> 
> > What is "guest userspace"?  Is that the userspace of the guest OS?
> >
> 
> Yes, assuming the OS itself already has ways to shoot itself in the foot
> by tampering with devices. But the userspace is in another layer, it
> could attempt to do bad things to the OS.

IIUC, from QEMU security pov, guest userspace or kernel shouldn't make much
difference.  Guest userspace messing up with guest kernel is the same as
when happening on bare metal in most cases?

There might be something more to exploit when hypervisor bug helps an
attacker, but again if we furtheradd migration into picture, that becomes:

  Guest userspace exploits that explicitly leverage a hypervisor bug
  _during_ migration to attach the guest OS

I agree if there is such a case it might be CVE candidate, but it's a bit
too detailed in my flavor to be put into a doc for demostration purpose..
Basically since migration is fully transparent we can add "during
migration" into all the hypervisor related scenarios..

Maybe we can simplify this to below?

  Guest crash or misbehave that can only be exploited during migration
  process

But this looks like what 1) was talking about, so maybe we can merge them
too?

> >> 
> >> 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?
> >
> 
> Right, this is a catchall meaning: even with all of the above, if
> someone finds a way to do this, the previous points do not invalidate
> this find.
> 
> I guess I wrote all of these with a sense of providing some assurance
> that even though we'll possibly be rejecting various bugs as
> non-security related, there are still clear situations where there's a
> security implication and we're aware of it.

Yes, I think from that POV maybe you're right we should still attach IN
SCOPE examples, but just to use some simpler wording and obvious examples
in the description.

For this one, it's about "data breach".  Can merge with 1) too?

> 
> >> 
> >> 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.
> 
> I don't think it matters if it would happen. If it ever does, we think
> it's bad enough that it will be considered for a CVE. "Considered", as
> opposed to just filing it as a normal bug. But the analysis could still
> result in nothing and we'd treat it as just a bug anyway.
> 
> > 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"..
> >
> 
> What I'm talking about in this particular point is about putting an
> admin in a situation where they can only resort to shutting down the
> virtual machine. This is a counterpart to the "failed migrations are
> normal" assumption up above; failed migrations can be easily worked
> around, but permanent failure cannot.

Yeah, that's OK.

> 
> > 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.
> 
> Fair point, maybe it's not super relevant indeed. Note I'm not trying to
> say that these items will become CVEs, just that if someone can put an
> argument that they can happen, then it's something we'll gladly look
> into.

IMHO if we want to have IN SCOPE, we should put whatever we're 100% sure is
CVE into IN SCOPE, and avoid mention things in-between.  Otherwise it may
make the document less clear, then less helpful in general.

It's the same to OUT OF SCOPE: when we see anything falls into that, we
should be confident to say "This is not a CVE candidate, please refer to
document XXX".

I used to suggest removal of IN SCOPE was only trying to make the first
version easier.  I agree having some would make sense even in the first
version, but maybe some rewording would be nice to make it very clear on
what it describes.

IMO it can still be as generic as this in one bullet covering a lot of
cases, meanwhile hopefully clear on what it describes:

  Any form of privilege escalation, data breach, guest crash [1] or
  hypervisor misbehave that requires migration process to trigger,
  successful or not.

  [1] guest crash only matters on whichever side is live.  For example, in
  a precopy setup, destination QEMU crash is normally benign and can easily
  fallback to source by a migration failure.  The guest crash described
  here should only include where it causes real damage to the guest VM by
  enforced shutdown or misbehave.

I'll leave decision to you on what you prefer as long as no objections
elsewhere; you have kudos drafting this, you deserve it.

Thanks!

-- 
Peter Xu

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

[Daniel P. Berrangé]

On Thu, Jul 16, 2026 at 03:34:20PM -0300, Fabiano Rosas wrote:
> 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.


Ok, can you rephrase that a little to make it more clear
that we are definitely *not* talking abut the guest owner
in this scenario. ie the saved state files are assumed to
be under control of the host mgmt app or host admin only,
so there's no privilege boundary involved.

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

The guest owner only controls what is accessible from their
VM, or what the mgmt APIs they're talking to allow for.

IOW, they should not be able to directly control the structure
of the migration stream vmstate data, nor the XML that libvirt
prepends, only payload in fields within the vmstate.

The issue is that's not the case today with at least some
mgmt apps I fear, but writing this down from QEMU's POV
will help clarify that.

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

So overall, I don't think this point has any influence on whether
we'll tag a bug as a security issue or not. This feels like just
guidance on usage of live migration.

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

So if we want to allow non-TLS then we need to combine the
two points to say:

   The migration connection must be either protected with TLS,
   or must run over a fully trusted (virtual private) network.

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

Two VMs configured with identical virtual hardware should have
the same vmstate structure, and so be compatible from the
POV of live migration flow. They can none the less have different
backend connections. So if tenant A can connect to a incoming
QEMU from tenant B, the live migration can probably succeed,
thus giving tenant A a working VM but with the HDD now backed
by data belonging to tenant B.


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

Yes.

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

We should probably have a standalone doc for migraton detailing
the recommended configuration scenarios, we could then link to
from this doc if needed.


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

I guess there could be a bug in the dest QEMU that trips up over
otherwise valid vmstate data. Dn't recall seeing an example of it
but never say never.


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