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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ