[PATCH 3/3] VFIO: Direct access config reg without capability
Alex Williamson
alex.williamson at redhat.com
Tue Mar 19 08:15:30 EST 2013
On Sat, 2013-03-16 at 06:30 +0100, Benjamin Herrenschmidt wrote:
> On Fri, 2013-03-15 at 13:41 -0600, Alex Williamson wrote:
> >
> > This basically gives userspace free access to any regions that aren't
> > covered by known capabilities.
>
> And ?
>
> I mean seriously :-) We already had that discussion ... trying to
> "protect" config space is just plain doomed. There is no point.
>
> It makes sense to do things like emulate BARs etc... for things to
> function properly under some circumstances/setups where you can't just
> expose the original BAR values to the guest and have the HW take care of
> it but you *must* be prepared to deal with anything in config space
> being changed without you knowing about it.
>
> Devices *will* have backdoors via MMIO. Period. You cannot rely on those
> not existing, whether they are documented or not.
>
> If you can't cope with the config space accesses then you aren't
> properly isolated. It can be deemed acceptable (depends what you use
> your VMs for) but that I mean is that any config space
> filtering/emulation for the sake of "security" is ... pointless.
>
> Doing it for functionality to work at all (ie BAR emulation) is fine,
> but that's about it. IE. As a mean of security it's pointless.
>
>
> > We have no idea what this might expose on some devices.
>
> No more than we have any idea what MMIO mapping of the device register
> space exposes :-)
Yeah, yeah. Ok, I can't come up with a reasonable argument otherwise,
it'll give us better device support, and I believe pci-assign has always
done this. I'll take another look at the patch. Thanks,
Alex
More information about the Linuxppc-dev
mailing list