linux-kernel - RE: [PATCH 0/4] KVM: Honor guest memory types for virtio GPU devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BN9PR11MB5276B5603D9D777F01D64EDA8C732@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Tue, 16 Jan 2024 04:05:08 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Jason Gunthorpe <jgg@...dia.com>, "Zhao, Yan Y" <yan.y.zhao@...el.com>
CC: "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

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

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