All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-arm@nongnu.org,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	qemu-ppc@nongnu.org, qemu-block@nongnu.org,
	qemu-riscv@nongnu.org, qemu-s390x@nongnu.org,
	"Eric Farman" <farman@linux.ibm.com>,
	"Cornelia Huck" <cohuck@redhat.com>
Subject: Re: [PATCH v2 02/28] hw: mark all virtio CCW devices as secure
Date: Fri, 6 Nov 2026 12:51:08 +0000	[thread overview]
Message-ID: <au3NPLpvDua_eefG@redhat.com> (raw)
In-Reply-To: <b3820b45-7d26-4b4a-aec7-cfcd5aaf5d96@redhat.com>

On Fri, Nov 06, 2026 at 12:38:09PM +0100, Thomas Huth wrote:
> On 29/10/2026 14.12, Daniel P. Berrangé wrote:
> > These are all intended for use in a virtualization scenario and must
> > provide a security boundary.
> > 
> > Acked-by: Eric Farman <farman@linux.ibm.com>
> > Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > Acked-by: Cornelia Huck <cohuck@redhat.com>
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> ...
> > diff --git a/hw/s390x/virtio-ccw-9p.c b/hw/s390x/virtio-ccw-9p.c
> > index d8612f7cd13..08d3ee577b4 100644
> > --- a/hw/s390x/virtio-ccw-9p.c
> > +++ b/hw/s390x/virtio-ccw-9p.c
> > @@ -64,6 +64,7 @@ static const TypeInfo virtio_ccw_9p_info = {
> >       .instance_size = sizeof(V9fsCCWState),
> >       .instance_init = virtio_ccw_9p_instance_init,
> >       .class_init    = virtio_ccw_9p_class_init,
> > +    .secure        = true,
> >   };
> I wonder whether we really want to include virtio-9p in the list of secure
> devices ... but in case we reconsider, I guess that can be refined later,
> so:

In terms of what we've documented about "virtualization use case"
being the criteria for security triage, I consider everything
related to virtio- to be already in-scope and not up for debate.
No one reading our current docs would expect anything "virtio" to
fall under the non-virtualization use case.

Now we have this explicit marker though, we can consider being more
fine grained in what we cover though. The question is how / when we
move a device from the "secure" to "not secure" bucket.

That direction should be very rare, because users need to have long
term certainty about what's treated secure. Our machine type
guarantees last for 6 years, 3 years of new VM deployments and
3 years deprecated where they should only be used for incoming
migrations/restores from saved state. Virtualization users / vendors
will expect security coverage for this kind of timeframe.

When we have maintainership problems with certain devices, if they
are marked secure, those are something we need to flag as priority
to various vendors like Red Hat who provide resource/investment
to QEMU. They're shipping this stuff and promising CVE fixes to
their paying customers and that needs to translate to investment
in QEMU upstream, though in the 9p case Red Hat does not actually
ship this particular device.

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



  reply	other threads:[~2026-11-06 12:51 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-29 13:12 [PATCH v2 00/28] Mark user creatable devices for secure for virt use case Daniel P. Berrangé
2026-10-29 13:12 ` [PATCH v2 01/28] hw: mark all virtio PCI devices as secure Daniel P. Berrangé
2026-11-06 11:35   ` Thomas Huth
2026-10-29 13:12 ` [PATCH v2 02/28] hw: mark all virtio CCW " Daniel P. Berrangé
2026-11-06 11:38   ` Thomas Huth
2026-11-06 12:51     ` Daniel P. Berrangé [this message]
2026-10-29 13:12 ` [PATCH v2 03/28] hw: mark all vhost devices a secure Daniel P. Berrangé
2026-11-06 11:39   ` Thomas Huth
2026-10-29 13:12 ` [PATCH v2 04/28] hw: mark all remaining virtio object types as secure Daniel P. Berrangé
2026-11-06 11:52   ` Thomas Huth
2026-11-06 14:35     ` Marc-André Lureau
2026-11-06 14:40       ` Daniel P. Berrangé
2026-11-06 14:52         ` Marc-André Lureau
2026-11-06 17:33           ` Daniel P. Berrangé
2026-11-12 19:01             ` Daniel P. Berrangé
2026-10-29 13:12 ` [PATCH v2 05/28] hw/vfio: mark all VFIO object classes " Daniel P. Berrangé
2026-11-06 11:54   ` Thomas Huth
2026-11-10 15:15   ` Cédric Le Goater
2026-10-29 13:12 ` [PATCH v2 06/28] hw/xen: mark all Xen related object types as being secure Daniel P. Berrangé
2026-10-29 13:12 ` [PATCH v2 07/28] hw/net: mark e1000, e1000e, IGB, rtl8139 & sPAPR VLAN as secure Daniel P. Berrangé
2026-11-06 11:57   ` Thomas Huth
2026-10-29 13:12 ` [PATCH v2 08/28] hw/usb: mark commonly used USB devices/hosts " Daniel P. Berrangé
2026-11-06 12:05   ` Thomas Huth
2026-11-06 12:21     ` Daniel P. Berrangé
2026-10-29 13:12 ` [PATCH v2 09/28] hw/watchdog: mark some watchdog devices " Daniel P. Berrangé
2026-11-06 12:14   ` Thomas Huth
2026-10-29 13:12 ` [PATCH v2 10/28] hw/scsi: mark spapr SCSI controller " Daniel P. Berrangé
2026-11-06 12:15   ` Thomas Huth
2026-10-29 13:12 ` [PATCH v2 11/28] hw/scsi: mark SCSI disk endpoint devices " Daniel P. Berrangé
2026-11-06 12:15   ` Thomas Huth
2026-10-29 13:12 ` [PATCH v2 12/28] hw/ide: mark ICH9 and ide-hd/ide-cd " Daniel P. Berrangé
2026-11-06 12:32   ` Thomas Huth
2026-10-29 13:12 ` [PATCH v2 13/28] hw: define most common PCI types " Daniel P. Berrangé
2026-11-06 12:16   ` Thomas Huth
2026-11-06 12:19   ` Thomas Huth
2026-10-29 13:12 ` [PATCH v2 14/28] hw/pci-host: mark common x86, ppc, arm and s390 PCI hosts " Daniel P. Berrangé
2026-11-06 12:38   ` Thomas Huth
2026-11-06 12:54     ` Daniel P. Berrangé
2026-10-29 13:12 ` [PATCH v2 15/28] hw/display: mark bochs, ramfb and VGA " Daniel P. Berrangé
2026-11-06 12:20   ` Thomas Huth
2026-10-29 13:12 ` [PATCH v2 16/28] hw/tpm: mark all TPM implementations " Daniel P. Berrangé
2026-10-29 13:12 ` [PATCH v2 17/28] hw/misc: mark pvpanic, vmcoreinfo " Daniel P. Berrangé
2026-10-29 13:12 ` [PATCH v2 18/28] hw/audio: mark Intel HDA devices & codecs " Daniel P. Berrangé
2026-10-29 13:12 ` [PATCH v2 19/28] hw/char: mark common serial / console devices " Daniel P. Berrangé
2026-10-29 13:12 ` [PATCH v2 20/28] hw/mem: mark nvdimm, pc-dimm & spapr-nvdimm " Daniel P. Berrangé
2026-11-06 12:40   ` Thomas Huth
2026-10-29 13:12 ` [PATCH v2 21/28] hw/uefi: mark the EFI vars service " Daniel P. Berrangé
2026-10-29 13:12 ` [PATCH v2 22/28] hw/acpi: mark erst, vmclock and vmgenid devices " Daniel P. Berrangé
2026-10-29 13:12 ` [PATCH v2 23/28] hw: mark KVM clock and RTC " Daniel P. Berrangé
2026-11-06 12:30   ` Thomas Huth
2026-10-29 13:12 ` [PATCH v2 24/28] hw: device AMD, Intel and ARM IOMMUs " Daniel P. Berrangé
2026-10-29 13:12 ` [PATCH v2 25/28] hw/input: mark PS/2 and PC Keyboard devices " Daniel P. Berrangé
2026-10-29 13:12 ` [PATCH v2 26/28] hw/i386: mark vmmouse / vmport " Daniel P. Berrangé
2026-10-29 13:12 ` [PATCH v2 27/28] hw/display: mark cirrus and QXL " Daniel P. Berrangé
2026-11-06 12:23   ` Thomas Huth
2026-11-06 14:32     ` Marc-André Lureau
2026-10-29 13:12 ` [PATCH v2 28/28] hw/usb: mark UHCI, OCHI & ECHI USB hosts " Daniel P. Berrangé
2026-11-06 12:28   ` Thomas Huth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=au3NPLpvDua_eefG@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=cohuck@redhat.com \
    --cc=farman@linux.ibm.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.