[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240116125426.GA734935@nvidia.com>
Date: Tue, 16 Jan 2024 08:54:26 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: "Tian, Kevin" <kevin.tian@...el.com>
Cc: "Zhao, Yan Y" <yan.y.zhao@...el.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"seanjc@...gle.com" <seanjc@...gle.com>,
"olvaffe@...il.com" <olvaffe@...il.com>,
"Lv, Zhiyuan" <zhiyuan.lv@...el.com>,
"Wang, Zhenyu Z" <zhenyu.z.wang@...el.com>,
"Ma, Yongwei" <yongwei.ma@...el.com>,
"vkuznets@...hat.com" <vkuznets@...hat.com>,
"wanpengli@...cent.com" <wanpengli@...cent.com>,
"jmattson@...gle.com" <jmattson@...gle.com>,
"joro@...tes.org" <joro@...tes.org>,
"gurchetansingh@...omium.org" <gurchetansingh@...omium.org>,
"kraxel@...hat.com" <kraxel@...hat.com>,
"zzyiwei@...gle.com" <zzyiwei@...gle.com>,
"ankita@...dia.com" <ankita@...dia.com>,
"alex.williamson@...hat.com" <alex.williamson@...hat.com>,
"maz@...nel.org" <maz@...nel.org>,
"oliver.upton@...ux.dev" <oliver.upton@...ux.dev>,
"james.morse@....com" <james.morse@....com>,
"suzuki.poulose@....com" <suzuki.poulose@....com>,
"yuzenghui@...wei.com" <yuzenghui@...wei.com>
Subject: Re: [PATCH 0/4] KVM: Honor guest memory types for virtio GPU devices
On Tue, Jan 16, 2024 at 04:05:08AM +0000, Tian, Kevin wrote:
> > From: Tian, Kevin
> > Sent: Tuesday, January 16, 2024 8:46 AM
> >
> > > From: Jason Gunthorpe <jgg@...dia.com>
> > > 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. :/
Next use may include things like swap to disk or live migrate the VM.
So it isn't quite so simple in the general case.
> > > 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.
Maybe, and on live migrate dma stop..
Jason
Powered by blists - more mailing lists