On Mon, Oct 05, 2026 at 03:30:09PM +0200, Philippe Mathieu-Daudé wrote: > On 11/9/26 16:36, Daniel P. Berrangé wrote: > > These have a long history of usage in virtualization scenarios on > > x86, for OS which lack modern virtio drivers for storage, and thus > > must be considered secure. > > > > Signed-off-by: Daniel P. Berrangé <[email protected]> > > --- > > hw/ide/ich.c | 1 + > > hw/ide/ide-dev.c | 3 +++ > > hw/ide/piix.c | 2 ++ > > 3 files changed, 6 insertions(+) > > > > @@ -252,6 +254,7 @@ static const TypeInfo ide_device_type_info = { > > .parent = TYPE_DEVICE, > > .instance_size = sizeof(IDEDevice), > > .abstract = true, > > + .secure = true, > > We shouldn't accept abstract secure device class IMO because it > will be to easy to merge new devices that ended secure and we do > not want to consider them. I'd go a step further and assert both > can not be set together.
Setting 'secure' in a parent device does NOT imply that all children have the same, only the reverse. ie, if a leaf device is secure, then by definition all its parents must be secure. This series only intended to mark leaf devices as secure, but a followup series will explicitly mark the whole parent chain as secure too, and also validate that chain in tests. Another followup is to require non-user creatable implied devices as secure. ie if a machine creates devices X, Y & Z, then if that machine is secure, then X, Y & Z must be considered secure too. Note, this would be just for those implied when "-nodefaults" is given. > > > .class_size = sizeof(IDEDeviceClass), > > .class_init = ide_device_class_init, > > .instance_init = ide_dev_instance_init, > 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 :|
