Re: [RFC PATCH] docs/system/security: Restrict "virtualization use case" to specific machines

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Oct 14, 2025 at 01:20:07PM +0100, Peter Maydell wrote:
> On Mon, 13 Oct 2025 at 12:47, Daniel P. Berrangé <berrange@redhat.com> 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 :|