|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 14/28] hw/ide: mark ICH9 and ide-hd/ide-cd as secure
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é <berrange@xxxxxxxxxx>
> > ---
> > 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 :|
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |