> From: Tian, Kevin > Sent: Tuesday, January 16, 2024 8:46 AM > > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > Sent: Tuesday, January 16, 2024 12:31 AM > > > > On Tue, Jan 09, 2024 at 10:11:23AM +0800, Yan Zhao wrote: > > > > > > Well, for instance, when you install pages into the KVM the hypervisor > > > > will have taken kernel memory, then zero'd it with cachable writes, > > > > however the VM can read it incoherently with DMA and access the > > > > pre-zero'd data since the zero'd writes potentially hasn't left the > > > > cache. That is an information leakage exploit. > > > > > > This makes sense. > > > How about KVM doing cache flush before installing/revoking the > > > page if guest memory type is honored? > > > > I think if you are going to allow the guest to bypass the cache in any > > way then KVM should fully flush the cache before allowing the guest to > > access memory and it should fully flush the cache after removing > > memory from the guest. > > For GPU passthrough can we rely on the fact that the entire guest memory > is pinned so the only occurrence of removing memory is when killing the > guest then the pages will be zero-ed by mm before next use? then we > just need to flush the cache before the 1st guest run to avoid information > leak. Just checked your past comments. If there is no guarantee that the removed pages will be zero-ed before next use then yes cache has to be flushed after the page is removed from the guest. :/ > > yes it's a more complex issue if allowing guest to bypass cache in a > configuration mixing host mm activities on guest pages at run-time. > > > > > Noting that fully removing the memory now includes VFIO too, which is > > going to be very hard to co-ordinate between KVM and VFIO. > Probably we could just handle cache flush in IOMMUFD or VFIO type1 map/unmap which is the gate of allowing/denying non-coherent DMAs to specific pages.
