On Mon, Sep 08, 2025 at 01:50:57PM +0100, Peter Maydell wrote: > Currently our security policy defines a "virtualization use case" > where we consider bugs to be security issues, and a > "non-virtualization use case" where we do not make any security > guarantees and don't consider bugs to be security issues. > > The rationale for this split is that much code in QEMU is older and > was not written with malicious guests in mind, and we don't have the > resources to audit, fix and defend it. So instead we inform users > about what the can in practice rely on as a security barrier, and > what they can't. > > We don't currently restrict the "virtualization use case" to any > particular set of machine types. This means that we have effectively > barred ourselves from adding KVM support to any machine type that we > don't want to put into the "bugs are security issues" category, even > if it would be useful for users to be able to get better performance > with a trusted guest by enabling KVM. This seems an unnecessary > restriction, and in practice the set of machine types it makes > sense to use for untrusted-guest virtualization is quite small. > > Specifically, we would like to be able to enable the use of > KVM with the imx8 development board machine types, but we don't > want to commit ourselves to having to support those SoC models > and device models as part of QEMU's security boundary: > https://lore.kernel.org/qemu-devel/20250629204851.1778-3-shen...@gmail.com/ > > This patch updates the security policy to explicitly list the > machine types we consider to be useful for the "virtualization > use case". > > This is an RFC partly to see if we have consensus that this change > makes sense, and partly because I was only able to identify the > machine types we want to cover for some of our target architectures. > If maintainers for the other architectures could clarify which > machine types work with KVM that would be helpful.
The split of "virtualization" vs "non-virtualization" use case in the docs was always as rather a crude hack. "Virtualization uses cases" was more or less a code phrase to mean "the subset of QEMU that we traditionally shipped in RHEL" as that is approximately what we have reasonable confidence about. Personally I wouldn't assign strict equivalence between "machine can use KVM" and "virtualization use case". Case in point - the "isapc" machine type can use KVM but I would not consider that to be a virtualization use case, and would likely reject a security report if it /only/ affected isapc, and not 'pc' / 'q35'. We didn't want to undertake the work to annotate every QOM/QDev impl in QEMU with info about whether we considered it in scope for security fixes or not, which is what we really ought to do at some point. The main challenge is someone having the time to do the audit & annotation work. > diff --git a/docs/system/security.rst b/docs/system/security.rst > index f2092c8768b..395c2d7fb88 100644 > --- a/docs/system/security.rst > +++ b/docs/system/security.rst > @@ -35,6 +35,34 @@ malicious: > Bugs affecting these entities are evaluated on whether they can cause damage > in > real-world use cases and treated as security bugs if this is the case. > > +To be covered by this security support policy you must: > + > +- use a virtualization accelerator like KVM or HVF > +- use one of the machine types listed below > + > +It may be possible to use other machine types with a virtualization > +accelerator to provide improved performance with a trusted guest > +workload, but any machine type not listed here should not be > +considered to be providing guest isolation or security guarantees, > +and falls under the "non-virtualization use case". > + > +Supported machine types for the virtualization use case, by target > architecture: > + > +aarch64 > + ``virt`` > +i386, x86_64 > + ``microvm``, ``xenfv``, ``xenpv``, ``xenpvh``, ``pc``, ``q35``, ``isapc`` > +s390x > + ``s390-ccw-virtio`` > +loongarch64: > + ``virt`` > +ppc, ppc64: > + TODO > +mips, mips64: > + TODO > +riscv32, riscv64: > + TODO Currently 'virtualization use case' is reasonably vague such that we can bend its scope as we desire, at the time it is questioned in a possible security report. Machine types are only one aspect of this. Devices are the other, and the area where it gets significantly more fuzzy and difficult because essentially any device can be used with KVM, and where we draw the line is fairly arbitrary. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
