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. -- 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
