Received-SPF: pass (google.com: domain of linux-kernel+bounces-26947-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+LZ1Ybo7DLoueAgAPOSYCAAIYUAIAAoD4AgAAM2ACAAB54gIAKXh0AgACHppCAADe5sA==
Date: Tue, 16 Jan 2024 04:05:08 +0000
Message-ID: <BN9PR11MB5276B5603D9D777F01D64EDA8C732@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> 
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?nWBN9rNHMm/JMd56MFiD5/X02nuuSfiRbKPchMYHJtp4YGrnsQ7FQsrQlc/k?=
 =?us-ascii?Q?8Dhq6P6alJTVaA6TQSnOKcR9xn/k4jHYeh4nkK2kZur2SnBXryzrDIRZqCO6?=
 =?us-ascii?Q?9PE9Jv2GEP8HpYyva2lMyPvdQMpg6N3QcfMMitEsDLGeNBMImhxKZInYg4A5?=
 =?us-ascii?Q?XY332RZOX9Tksno8rWRvJd7BC5Ml3r/zttJjku1wNsENLyS4ZI7Cy+7dPCYv?=
 =?us-ascii?Q?3fblsjXzWmtR2ozNU8wIcY8ddKJedAMhOrNoI34XxTcZlRfbORJtJ4YqomGr?=
 =?us-ascii?Q?kRAeJOIFMB+cXlklu7MIfsvO9SWnuaPI7bS8cbEHSKgmmgQCTp8ozoh2CTFV?=
 =?us-ascii?Q?iJsaKTWFrpcJhCOk4Z/PjYZJz8x8P6f6XT+iZD49Vy7XsO8gpdoDcW2ysOXX?=
 =?us-ascii?Q?4IqD+wcJZIpJ976llC2Z95jVcT2wDcEvgKayYZ3x1qUwzkkKUbYrTSSZ26zB?=
 =?us-ascii?Q?NTqdZUhoX6e0iMOHV6Sn7CUrShSAiDZ0QxX1yhGnWoMvTX29jeF/osb5mXlh?=
 =?us-ascii?Q?lnzm43HOYDixtolqiSKO3o3rtEQEb/T2NPKEUWQF61Aetd+AF1JVhV8oSDjL?=
 =?us-ascii?Q?w+OyNDbo1ebIZe4BwQDg2fPtJgQFAzrGbkh6RsYNVqOg9KwomQNWkpAHX49i?=
 =?us-ascii?Q?Cjtiz7oP4xMjvqjMK0z1nIc34qjj8+Z7GK4SKTefJVDBSckoGE9fdaAxOiC3?=
 =?us-ascii?Q?1+R7Lt0EIc5NZ5X93OOFmZ3QR5Ofzk7VrU8B4Uylk+QLFur6KQPFDGDcIt92?=
 =?us-ascii?Q?0sZPKr4Rm8ewYAybBuou8MZ+JeVK5qzw8C31mUe52zX3XSO2s2l4o8+oOTWU?=
 =?us-ascii?Q?2VMP4ftYbveipUA6lai8SzBOvV6DMWnL0SEKRl2I/w24+zm2CJLBiw1ZF6zP?=
 =?us-ascii?Q?PiGBi4FRTszHfP6rIYv7tV8ao92ZNfpJ6nEz9/btb9Tor5+jtmmdvwIuhUr1?=
 =?us-ascii?Q?6mjB0x7cdOtOk/AVWa1uAXIocym4xfaHKz+9IBaaLXK5u9UOSTZMRoXbUGQ9?=
 =?us-ascii?Q?aFwPxr8o1QLgTmqr+M12cFVdO4sPS3qx6m3qCGuPiu6436xu23FAnnbzCeIC?=
 =?us-ascii?Q?6bkiZfdX2IdFsee662GwBvRhn2rRehdfzyW5j1cNtH9i5jSxFnBzs2q5tr9s?=
 =?us-ascii?Q?wjGVewnj2f8KNCKWA4gvtcavm7LQIiIOtoDD5xF/D63+Q64HAC5AnBGGAQ2p?=
 =?us-ascii?Q?pPW0edlSO7SbJ/tCL8sL+lYe87Ugg1x20de67tIrYG4Kbr8t51XWRZ3j4dDB?=
 =?us-ascii?Q?XSOIIP3c5szGWFyHkTYuqO8rmU0iVkJNKjcxU7WN8LbiuP4Fgpzr67qIh0LV?=
 =?us-ascii?Q?vxYgZyZ93la+fBqkPj5S1i8c5MFY06HPu37iMvHvncAens/oanO0AZVQWyP4?=
 =?us-ascii?Q?WYRIeuHSDoWxb5l1sHOMjhRVIIcsI6lReiF7bIAVJuuYP3xWkbi8OZYq7ruD?=
 =?us-ascii?Q?I9sqSbNpgTVtlJeewXSIUL7+utRGE/Fn5vL2DZrTFDOCqOvrnRdFystZXo5z?=
 =?us-ascii?Q?67OA2xN1w0TAXYfR21iXKWGnlV1JdESyVVQVCiowCjZTM+e+6wC+QFsg7ki4?=
 =?us-ascii?Q?Q7Uy2eka93bbvw7XEVi+bqQL1WhCLfulZWWhax3K?=
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: 78d05ba9-2ca9-45ee-1e7e-08dc164853e9
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2024 04:05:08.0886
 (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: yHCXk+8JyUcK2wZrzBvZk3nhP7VMhG0cvw9FgbqyLxQv/ZVsZg0V3w3JM9YY7eejUpwfdYkCnHE2sa16H4wmFA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR11MB7813
X-OriginatorOrg: intel.com

> From: Tian, Kevin
> Sent: Tuesday, January 16, 2024 8:46 AM
>=20
> > From: Jason Gunthorpe <jgg@nvidia.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 hypervi=
sor
> > > > 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.
>=20
> 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 informatio=
n
> 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. :/

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

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.