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: <BN9PR11MB52763D5A686C855CD74766BA8C732@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Tue, 16 Jan 2024 00:45:56 +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: 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.

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.

if only talking about GPU passthrough do we still need such coordination?

> 
> ARM has the hooks for most of this in the common code already, so it
> should not be outrageous to do, but slow I suspect.
> 
> Jason