Re: [PATCH 3/3] VFIO: Direct access config reg without capability

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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

>   I'd like to support be2net, but what's the minimal
> access that it needs?  Can we provide 2 or 4 bytes of read-only access
> at offset 0x7c for just that device?  Is it always 0x7c?  Let's split
> this patch from the series since it's clearly dealing with something
> independent.  Thanks,

Ben.