Re: [PATCH 01/28] hw: mark secure machines for x86, s390, ppc, arm, loonarch, riscv

[Daniel P. Berrangé <berrange@xxxxxxxxxx>]

On Mon, Oct 05, 2026 at 03:34:52PM +0200, Philippe Mathieu-Daudé wrote:
> On 5/10/26 15:23, Daniel P. Berrangé wrote:
> > On Mon, Oct 05, 2026 at 03:06:08PM +0200, Philippe Mathieu-Daudé wrote:
> > > Hi,
> > > 
> > > On 11/9/26 16:36, Daniel P. Berrangé wrote:
> > > > The versioned machine types are typically present for use in
> > > > virtualization use cases and can be expected to provide a security
> > > > barrier. The only exceptions are the m68k versioned machine types
> > > > which are only used with TCG. There are also a handful of other
> > > > machines declared secure in docs/system/security.rst, notably
> > > > the Xen machine variants and microvm.
> > > > 
> > > > Signed-off-by: Daniel P. Berrangé <berrange@xxxxxxxxxx>
> > > > ---
> > > >    hw/arm/virt.c              | 1 +
> > > >    hw/arm/xen-pvh.c           | 1 +
> > > >    hw/i386/microvm.c          | 1 +
> > > >    hw/i386/pc_piix.c          | 4 ++--
> > > >    hw/i386/xen/xen-pvh.c      | 1 +
> > > >    hw/loongarch/virt.c        | 2 ++
> > > >    hw/ppc/spapr.c             | 1 +
> > > >    hw/riscv/virt.c            | 1 +
> > > >    hw/s390x/s390-virtio-ccw.c | 1 +
> > > >    hw/xen/xen-pvh-common.c    | 1 +
> > > >    hw/xenpv/xen_machine_pv.c  | 2 +-
> > > >    include/hw/i386/pc.h       | 1 +
> > > >    12 files changed, 14 insertions(+), 3 deletions(-)
> > > 
> > > This patch should be split per machine / area of maintenance,
> > > so maintainers can officially Ack their commitment to security
> > > boundary for their machine.
> > > 
> > > I'm not sure LoongArch / RISCV / PPC are. If this was previously
> > > discussed, then pointer to the public discussions should be listed
> > > in the patch description.
> > 
> > Those are explicitly documented here:
> > 
> >    
> > https://www.qemu.org/docs/master/system/security.html#virtualization-use-case
> > 
> > so this patch is just encoding what has already been defined.
> 
> I probably missed when this was accepted, we are good then!
> 
> That said, 1/ Nitro Enclave are missing and 2/ this series organization
> is not easy to follow to me: I'd rather a per-machine approach, with a
> 'info qom-tree' output justifying the devices, then finish the series
> with busses-based devices expected to be secure. I dont quite follow
> this approach. I'm not asking to redo the series since it is already
> reviewed.

The structure is essentially, the machines listed in the docs, the
hardware accelerators, the paravirtualized devices, and then per
subsystem devices for the rest.

A per-machine approach would end up with 90% of the series added
in the first patch, as most devices are common to all machines
or targets.

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