Received-SPF: pass (google.com: domain of linux-kernel+bounces-20208-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Mon, 8 Jan 2024 20:22:20 -0400
From: Jason Gunthorpe <jgg@nvidia.com>
To: Yan Zhao <yan.y.zhao@intel.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, pbonzini@redhat.com,
	seanjc@google.com, olvaffe@gmail.com, kevin.tian@intel.com,
	zhiyuan.lv@intel.com, zhenyu.z.wang@intel.com, yongwei.ma@intel.com,
	vkuznets@redhat.com, wanpengli@tencent.com, jmattson@google.com,
	joro@8bytes.org, gurchetansingh@chromium.org, kraxel@redhat.com,
	zzyiwei@google.com, ankita@nvidia.com, alex.williamson@redhat.com,
	maz@kernel.org, oliver.upton@linux.dev, james.morse@arm.com,
	suzuki.poulose@arm.com, yuzenghui@huawei.com
Subject: Re: [PATCH 0/4] KVM: Honor guest memory types for virtio GPU devices
Message-ID: <20240109002220.GA439767@nvidia.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>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZZyG9n0qZEr6dLlZ@yzhao56-desk.sh.intel.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?/KpMPlNWNd/6Og0YOleucIlCQXkKZEVhE+LWCCMJnocy3jn9Tdeg1nZPW/zz?=
 =?us-ascii?Q?K/hGqaHIVxMHdeHqcsre/3Vcart3NZaKGO2F6GKxZ+iWvsUZF4H6DVgIe7q0?=
 =?us-ascii?Q?owA9Pf978tYVGsBx3j6WDyINcUX6Iw8X9Esspt7TX0ayW/3tQhktCn28HRap?=
 =?us-ascii?Q?TrKdI/ALr7u/iIWgHw/s7W17/SNEs5L9KDB69ha2mpdvQbfAZPPC5tA+2PZB?=
 =?us-ascii?Q?JpUuE0x/sCXLRz3p1D7LmKNDLaTuZiLZUTLO2NHRLeA8GDv16C3OCGLlVO+6?=
 =?us-ascii?Q?mSBuKox0FZX08M2kOIAVLdJ0ASgZMFMf6J/XFhlKFcGAg32wkXh3sDaobOvX?=
 =?us-ascii?Q?iNOyW49CLPI2UNXsJ8sHnYSqqoe7taEik+uc+xTsV4W7fpOcjHfPqVHTx8Rq?=
 =?us-ascii?Q?Zf6lIcZj11rumY/R0t5ggWmxarwzoABTfpYHmARumaOMFES76rxUipctiTCs?=
 =?us-ascii?Q?VDUR6sVVq+Cqtclpm56fM06L81DUGs49dxgOatAYaSRo65SXCSn7gsevih44?=
 =?us-ascii?Q?6ohEJQv2NJesu70rLMQv6JFr0XV5JNTOgaw5Y/8x6ekdTBDsDanRdBPlMpRm?=
 =?us-ascii?Q?lGyU98JOw4+O1/mzRxvTl7FLXocPwsO0MT1nqAXkfS3ApIrpRwug9NKW0MeT?=
 =?us-ascii?Q?nuli12ChRgTu/uQKjj6KUugaSxWQY7UXuxlASxJrYJJgtgtgDNp5Rn2sxND/?=
 =?us-ascii?Q?IvwEQBekLTKa/+5THLTHyR7xpRzu9Gg6PYdQNpo8Qbp1kf0rqL49tOmvF52O?=
 =?us-ascii?Q?8c0pZsEZAAVQgfk5kuuG81GrObzjcDJcD/cn63XBf4c9YZAGkRjas4Q8TKal?=
 =?us-ascii?Q?vZBE/dtpHqmlgKFdEFh8hDFtfX0H64XVJjL9Lfe7gdGHa5Q3WSVDipDxiNYp?=
 =?us-ascii?Q?SIST9jU/Jl+hyWADMeyTdTmqZzG7W/0u6ndZflsd3Y0YhGAQLkKtg6ffUNZi?=
 =?us-ascii?Q?sDTzhRPYVC7T3zm61ZlhllsLii7YDcBs69XIbfADFjd+6CrirywQofKto6ON?=
 =?us-ascii?Q?BFRsATXMQZTHP2+nkTIwBEpQX6y70tmcyjEeobhvdJv93UisR03XG9Bbu0+Y?=
 =?us-ascii?Q?cEJu5md7Skqt7tZP5RkKyBUf0hzsINsMd05bp1zatM3uqHlP2KIG4ICR5I8l?=
 =?us-ascii?Q?xco0zjP4/ok/9XPfQ7CkBTNYzSGQ/rB6eNW+8R7ZECYKnd+dW1Zc9D2eYDbj?=
 =?us-ascii?Q?SxVsXkyGZuNuP1OrIM+BMbkod9WRa7OsYDY+QNvE8Nms2vtkM9jbez3iuGkR?=
 =?us-ascii?Q?dkwZ4tRimFRF05v8mT0VLpd8RI7/MwsAO26ngp0PAVNVauWqTT+FwF4eKRLx?=
 =?us-ascii?Q?iTqzHHzJmpH7QuTyzapK1/V2F/qTPbO/11OKaOVYg/I7riIX7VpuXAbOg2yf?=
 =?us-ascii?Q?J0GjcssOF70YjnSxDwxLfQVbRABXnoxRzWwEQPPx2aqpGVTI/SJCZMoYeQXE?=
 =?us-ascii?Q?8xE6iu4udFDbkgK7ZA3/rgt1GmlK2xNyA/b5u980Xt4U6fD3HcPU/luFFccJ?=
 =?us-ascii?Q?LNdyjT4udMIr+NfkXknqhL6rrwqZhal2YUj5PuigHR+ABTzCKPixZf2suvlv?=
 =?us-ascii?Q?LUIo3yLbZ7qt8BqbuDHLwif0qgnwZxv7fo/JyUb+?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a9f06772-903f-4c22-a98e-08dc10a90c10
X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2024 00:22:21.9278
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 9s6WDLG+l8RKTw44sZDh4vkVfwVcD1xTEaaLtiAAsgkzy5A8AwYZM5YM6QrybzBQ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9409

On Tue, Jan 09, 2024 at 07:36:22AM +0800, Yan Zhao wrote:
> On Mon, Jan 08, 2024 at 10:02:50AM -0400, Jason Gunthorpe wrote:
> > On Mon, Jan 08, 2024 at 02:02:57PM +0800, Yan Zhao wrote:
> > > On Fri, Jan 05, 2024 at 03:55:51PM -0400, Jason Gunthorpe wrote:
> > > > On Fri, Jan 05, 2024 at 05:12:37PM +0800, Yan Zhao wrote:
> > > > > This series allow user space to notify KVM of noncoherent DMA status so as
> > > > > to let KVM honor guest memory types in specified memory slot ranges.
> > > > > 
> > > > > Motivation
> > > > > ===
> > > > > A virtio GPU device may want to configure GPU hardware to work in
> > > > > noncoherent mode, i.e. some of its DMAs do not snoop CPU caches.
> > > > 
> > > > Does this mean some DMA reads do not snoop the caches or does it
> > > > include DMA writes not synchronizing the caches too?
> > > Both DMA reads and writes are not snooped.
> > 
> > Oh that sounds really dangerous.
> >
> But the IOMMU for Intel GPU does not do force-snoop, no matter KVM
> honors guest memory type or not.

Yes, I know. Sounds dangerous!

> > Not just migration. Any point where KVM revokes the page from the
> > VM. Ie just tearing down the VM still has to make the cache coherent
> > with physical or there may be problems.
> Not sure what's the mentioned problem during KVM revoking.
> In host,
> - If the memory type is WB, as the case in intel GPU passthrough,
>   the mismatch can only happen when guest memory type is UC/WC/WT/WP, all
>   stronger than WB.
>   So, even after KVM revoking the page, the host will not get delayed
>   data from cache.
> - If the memory type is WC, as the case in virtio GPU, after KVM revoking
>   the page, the page is still hold in the virtio host side.
>   Even though a incooperative guest can cause wrong data in the page,
>   the guest can achieve the purpose in a more straight-forward way, i.e.
>   writing a wrong data directly to the page.
>   So, I don't see the problem in this case too.

You can't let cache incoherent memory leak back into the hypervisor
for other uses or who knows what can happen. In many cases something
will zero the page and you can probably reliably argue that will make
the cache coherent, but there are still all sorts of cases where pages
are write protected and then used in the hypervisor context. Eg page
out or something where the incoherence is a big problem.

eg RAID parity and mirror calculations become at-rist of
malfunction. Storage CRCs stop working reliably, etc, etc.

It is certainly a big enough problem that a generic KVM switch to
allow incoherence should be trated with alot of skepticism. You can't
argue that the only use of the generic switch will be with GPUs that
exclude all the troublesome cases!

> > > In this case, will this security attack impact other guests?
> > 
> > It impacts the hypervisor potentially. It depends..
> Could you elaborate more on how it will impact hypervisor?
> We can try to fix it if it's really a case.

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.

Who knows what else you can get up to if you are creative. The whole
security model assumes there is only one view of memory, not two.

Jason