On 10.12.2009, at 06:16, Muli Ben-Yehuda wrote: > On Wed, Dec 09, 2009 at 06:38:54PM +0100, Alexander Graf wrote: > >> While trying to get device passthrough working with an emulex hba, >> kvm refused to pass it through because it has a BAR of 256 bytes: >> >> Region 0: Memory at d2100000 (64-bit, non-prefetchable) [size=4K] >> Region 2: Memory at d2101000 (64-bit, non-prefetchable) [size=256] >> Region 4: I/O ports at b100 [size=256] >> >> Since the page boundary is an arbitrary optimization to allow 1:1 >> mapping of physical to virtual addresses, we can still take the old >> MMIO callback route. >> >> So let's add a second code path that allows for size & 0xFFF != 0 >> sized regions by looping it through userspace. > > That makes sense in general *but* the 4K-aligned check isn't just an > optimization, it also has a security implication. Consider the > theoretical case where has a multi-function device has BARs for two > functions on the same page (within a 4K boundary), and each function > is assigned to a different guest. With your current patch both guests > will be able to write to each other's BARs. Another case is where a > device has a bug and you must not write beyond the BAR or Bad Things > Happen. With this patch an *unprivileged* guest could exploit that bug > and make bad things happen. > > This can be fixed if the slow userspace mmio path checks that all MMIO > accesses by a guest fall within the portion of the page that is > assigned to it. That's exactly what this patch does. It only allows access to the region defined in the BAR. 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
