On Tue, Oct 14, 2025 at 01:20:07PM +0100, Peter Maydell wrote: > On Mon, 13 Oct 2025 at 12:47, Daniel P. Berrangé <[email protected]> wrote: > > With a very minimal wording tweak our current defined policy could > > avoid being a blocker for enabling KVM in imx8mp-evk. In > > > > https://www.qemu.org/docs/master/system/security.html > > > > where it describes the "virtualization use case", we could simply > > tweak it to always require a versioned machine type > > > > Change > > > > "These use cases rely on hardware virtualization extensions > > to execute guest code safely on the physical CPU at close- > > to-native speed." > > > > To say > > > > "These use cases apply to versioned machine types when used > > in combination with hardware virtualization extensions > > to execute guest code safely on the physical CPU at close- > > to-native speed" > > With the suggested changes listed elsewhere in this > thread, my current manually curated list of machines is: > > aarch64 > ``virt`` > i386, x86_64 > ``microvm``, ``xenfv``, ``xenpv``, ``xenpvh``, ``pc``, ``q35`` > s390x > ``s390-ccw-virtio`` > loongarch64: > ``virt`` > ppc64: > ``pseries`` > riscv32, riscv64: > ``virt`` > > If we say "versioned machine type", that puts these machines > outside the "supported" boundary: > > i386, x86_64 > ``microvm``, ``xenfv``, ``xenpv``, ``xenpvh`` > loongarch64: > ``virt`` > riscv32, riscv64: > ``virt`` > > I can certainly see the argument for loongarch64 > and maybe even riscv[*] still being "not supported for > production security-boundary stuff", but do we really > want to say that the Xen machine types and microvm > aren't suitable for VM use ?
No, that would be wrong. How about this alternative @@ -21,7 +21,9 @@ Virtualization Use Case The virtualization use case covers cloud and virtual private server (VPS) hosting, as well as traditional data center and desktop virtualization. These use cases rely on hardware virtualization extensions to execute guest code -safely on the physical CPU at close-to-native speed. +safely on the physical CPU at close-to-native speed. This use case is limited +to the use of versioned machine types, or machine types designed exclusively +for virtualization. The following entities are untrusted, meaning that they may be buggy or malicious: that wording would bring xen* and microvm into the scope, and so match your manually curated list. > [*] Could somebody from riscv or loongarch maintainers > say whether they think these machines should be on the > "security supported" list or not yet ? As 'virt' machines even if they're not quite there today, they are heading in that direction. So it would make sense to consider them in scope for the virtualization use case security handling. Even with this classification we still have the flexibility to make bugs public immediately with no embargo if we consider the real world impact to be low, so the burden is not large. 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 :|
