Re: [PATCH 00/28] Mark user creatable devices for secure for virt use case

[marcandre.lureau@xxxxxxxxxx]

Hi

> This (largish) series undertakes the task of marking devices
> secure, if they are intended to be used a virtualization
> use case.
> 
> NB, the maintainer CC list was way too huge to include every
> individual, so I've trimmed to just the mailing list CCs.
> 
> The approach taken was iterative as follows
> 
>  * Machines listed in
> 
>     
> https://www.qemu.org/docs/master/system/security.html#virtualization-use-case
> 
>  * All virtio/vhost/vfio/xen related devices
> 
>  * Most PCI related devices/controllers/bridges
> 
> I then used the RHEL builds of QEMU as an approximation for
> what should be considered "virtualization use case", since
> they cut out a huge pile of devices from the build. IOW,
> more or less everything that RHEL builds for x86_64, ppc64,
> aarch64, s390x gets included. Notably since RHEL does not
> yet ship riscv or loongarch, I've possibly missed some
> devices that ought to be in scope.

I don't see many maintainers against your proposal. I guess we can assume they
agree?  I think this will really help us deal with bug triaging and priorities,
so I wish it would land already..

> Devices are marked secure *regardless* of their maintainer
> status, if they are relevant to virt. Notably all the USB
> stuff is included despite USB being orphaned. An exception
> is CXL which is arguably relevant to virt, but maintainers
> agreed it is too immature to include so far.
> 
> IOW, the "secure" flag as set in this series mostly avoids
> saying anything about the support status of the object types.
> 
> Over the long term, IMHO, the set of devices we declare as
> providing a security boundary needs to be stable. We should
> not declare a device out of scope for the virt use case simply
> because a maintainer steps aside. The device doesn't become
> instantly less secure. It does mean bug fixes may not be
> timely enough, and rely on the goodwill of other contributors
> or maintainers to step up and fix.
> 
> Or to put it another way. "secure = true" does not guarantee
> that the device is secure, but it states our intent that we
> *want* it to be secure, as opposed to "secure = false" which
> indicates we just don't care either way.
> 
> The intersection of (secure, orphaned) highlights to QEMU
> contributors or corporate sponsors, where they might step
> up their effort / investment.
>
> Finally this is just user creatable devices. Use of these
> devices implies use of many more non-user creatable devices.

Right, and I also figured out while reviewing this that CLI -vga/-nic/-drive
creation paths are not being checked yet. I can look at it if it helps

-- 
Marc-André Lureau <marcandre.lureau@xxxxxxxxxx>