Received-SPF: pass (google.com: domain of linux-kernel+bounces-26807-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>, "Zhao, Yan Y" <yan.y.zhao@intel.com>
CC: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>, "seanjc@google.com"
	<seanjc@google.com>, "olvaffe@gmail.com" <olvaffe@gmail.com>, "Lv, Zhiyuan"
	<zhiyuan.lv@intel.com>, "Wang, Zhenyu Z" <zhenyu.z.wang@intel.com>, "Ma,
 Yongwei" <yongwei.ma@intel.com>, "vkuznets@redhat.com" <vkuznets@redhat.com>,
	"wanpengli@tencent.com" <wanpengli@tencent.com>, "jmattson@google.com"
	<jmattson@google.com>, "joro@8bytes.org" <joro@8bytes.org>,
	"gurchetansingh@chromium.org" <gurchetansingh@chromium.org>,
	"kraxel@redhat.com" <kraxel@redhat.com>, "zzyiwei@google.com"
	<zzyiwei@google.com>, "ankita@nvidia.com" <ankita@nvidia.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>, "maz@kernel.org"
	<maz@kernel.org>, "oliver.upton@linux.dev" <oliver.upton@linux.dev>,
	"james.morse@arm.com" <james.morse@arm.com>, "suzuki.poulose@arm.com"
	<suzuki.poulose@arm.com>, "yuzenghui@huawei.com" <yuzenghui@huawei.com>
Subject: RE: [PATCH 0/4] KVM: Honor guest memory types for virtio GPU devices
Thread-Topic: [PATCH 0/4] KVM: Honor guest memory types for virtio GPU devices
Thread-Index: AQHaP7tymmMn9RzSAkmqnV+LZ1Ybo7DLoueAgAPOSYCAAIYUAIAAoD4AgAAM2ACAAB54gIAKXh0AgACHppA=
Date: Tue, 16 Jan 2024 00:45:56 +0000
Message-ID: <BN9PR11MB52763D5A686C855CD74766BA8C732@BN9PR11MB5276.namprd11.prod.outlook.com>
References: <20240105091237.24577-1-yan.y.zhao@intel.com>
 <20240105195551.GE50406@nvidia.com>
 <ZZuQEQAVX28v7p9Z@yzhao56-desk.sh.intel.com>
 <20240108140250.GJ50406@nvidia.com>
 <ZZyG9n0qZEr6dLlZ@yzhao56-desk.sh.intel.com>
 <20240109002220.GA439767@nvidia.com>
 <ZZyrS4RiHvktDZXb@yzhao56-desk.sh.intel.com>
 <20240115163050.GI734935@nvidia.com>
In-Reply-To: <20240115163050.GI734935@nvidia.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?A1J1teEvyf+xwG6JmwLEf8rgJar7wRz+1KF36sIkIw+IsD58KmlDBz8xZqdt?=
 =?us-ascii?Q?Dt4PEMgXER0a45pVr4cVqCKnHSLFAX8mA5UogwVKLYmP9Dlq7TcvW9NKe2XI?=
 =?us-ascii?Q?eKgPnMz4ReQCCKU0xd0M2aZ5SGzpksRvYsJAjkfPeXQgLTRB5AfNgVu2wnqU?=
 =?us-ascii?Q?rrYYNSonu43DQf/hxZ1wHS/6GawsacLN2p59jEF5WhRre0am8eK9yk+mc9rb?=
 =?us-ascii?Q?Ncc99YTKEDXiuP4niFkP7KgNUE7Qht3lnS3H2/fBgRESnYMQsu3W7+UgDf3G?=
 =?us-ascii?Q?h8mI8v9qxzlLehYWgsDEGhN0jJqSm+jITnxsbWVJECwwfl5CN+2bII7pEYOb?=
 =?us-ascii?Q?drRwr5Qhj4demokwF1kjc5m7J3jpSU+eAwgxkR6+HlFnNRsETKQq7nZoocmZ?=
 =?us-ascii?Q?FbeV8Y2H1vK9q44ABACReMFZZIPG+yg31iUtoqPo1KT/sEug6XV8oZd3zp+H?=
 =?us-ascii?Q?/kl2RsAtDDNmF2Ex1cv1aupg9QtMU84wxiwI79/zHokxYFWxum1ajNcX7P1j?=
 =?us-ascii?Q?X6kiigzqvyRrFoE6eGtsfS7eJtIAiwaPGonebM37Orlmv+IDaXI6DiyeHER9?=
 =?us-ascii?Q?R/uO5xeFPqnZQOBYX+t1oX+NNkZ4Bv1wXJpsrzZREqn8rM9i3IRhRBw07pl/?=
 =?us-ascii?Q?UoTkCe0VyFTkiyVwJvWIFJjtDAZxFKn7GFIhVu5HnzMJtoGFTKMTsJ8w3Cmt?=
 =?us-ascii?Q?KvJ1y+WDdOwKyAYNoA846ajoo1CbmWn1x9/5Av2ZksGZni4Qr+0pwviW+yjO?=
 =?us-ascii?Q?x0GlgWuOzfl/9AB8TzXgG1ArPR3Ed/FLXHoTi8MA5l/V3TGgRtm2iH/8K5Zm?=
 =?us-ascii?Q?v5FgGbvpuOeIIQO71g2/z2OBJzUHzTMYxc9JjUoZ4ojWmWos8jolioe8ah9M?=
 =?us-ascii?Q?a+0z7Aufka7vEWgW+QBco3vVaX4RGOjkyaxy3HTyPjtNoF2Se0OiWacDLjcY?=
 =?us-ascii?Q?189rqfItOJaV7Q5R6BInP17HKlku5Nzjw7c3A1vA5S/PU5I708GSkGO6zWYI?=
 =?us-ascii?Q?Tkt/lGMvh+PuQNn6co6fY9i/Jt5AQTWMoGSBxxVCDtK3dsuiE4TPq0kiZ3vg?=
 =?us-ascii?Q?zV6wwIs7CZNqXclXbVD8ka1sciycIYmvAv9qY3wuADFoxsRvctW7pkS9ibbP?=
 =?us-ascii?Q?9R12kD0uf0sLiaRi3jW/ijE2/wgxoPMI/H+kEgIQjsdtEXSlQ+YMLAn7l9ge?=
 =?us-ascii?Q?/24KklxeedSgtgeUCyrxATgsGSYeOdTCSSFD3EhHCGIH2OS6ZpL/n9GKPiJs?=
 =?us-ascii?Q?oIP1SNEEO9iJz7pOYwHqn6aMd3LXtFqWGC/n5/b9enFPWyRN2cX4iJ6p4b2P?=
 =?us-ascii?Q?ce5aAt03JdEyc2c5q3z0CWyH9puojAeC0SmnbU0vqTJvc/89BqfmRFVhHzkt?=
 =?us-ascii?Q?7+kUs8GhrDzsasRQeVFIJFlD6LAjQpmDyYp3EVFpjh5jHXaLckwdp/EHn/Nt?=
 =?us-ascii?Q?5TQdtcxCgKCZy/JIUbU4els482Dq28q4ILlhEbTlVvpNmFUW7jqjdJvK2opZ?=
 =?us-ascii?Q?3q4TQw7TrxSBCpD3ES2hXfTKChGo33JVKox33zpH+iyhcdKfv9xvLpQ7OQDF?=
 =?us-ascii?Q?Jf1e788orugfs803t2Lxy6oj6nxBBAeGHCPiSDDs?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5276.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 392f6053-51ec-450c-b4e1-08dc162c8049
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2024 00:45:56.6167
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vBXtN4/KN3PuBIxcCpwirkv8adIZAtS4jgtZ8ACM7SS/Q3mn28R0CieUOrNBmRx28qZfT5robmXlM/XnnHKPpw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR11MB7724
X-OriginatorOrg: intel.com

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Tuesday, January 16, 2024 12:31 AM
>=20
> On Tue, Jan 09, 2024 at 10:11:23AM +0800, Yan Zhao wrote:
>=20
> > > Well, for instance, when you install pages into the KVM the hyperviso=
r
> > > 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?
>=20
> 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.

>=20
> 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?

>=20
> 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.
>=20
> Jason