On Sat, 2013-03-16 at 06:30 +0100, Benjamin Herrenschmidt wrote:

On Fri, 2013-03-15 at 13:41 -0600, Alex Williamson wrote:

quoted

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.

quoted

 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