On Thu, Jul 16, 2026 at 11:08:49AM -0300, Fabiano Rosas wrote: > Daniel P. Berrangé <[email protected]> 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é <[email protected]> > >> 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é <[email protected]> > >> > --- > >> > > >> > 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
