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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
