linux-kernel - Re: [PATCH v2 1/1] KVM: arm64: Allow cacheable stage 2 mapping using VMA flags

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] [day] [month] [year] [list]

Message-ID: <20250117191604.GF5556@nvidia.com>
Date: Fri, 17 Jan 2025 15:16:04 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Catalin Marinas <catalin.marinas@....com>
Cc: Ankit Agrawal <ankita@...dia.com>, David Hildenbrand <david@...hat.com>,
	"maz@...nel.org" <maz@...nel.org>,
	"oliver.upton@...ux.dev" <oliver.upton@...ux.dev>,
	"joey.gouly@....com" <joey.gouly@....com>,
	"suzuki.poulose@....com" <suzuki.poulose@....com>,
	"yuzenghui@...wei.com" <yuzenghui@...wei.com>,
	"will@...nel.org" <will@...nel.org>,
	"ryan.roberts@....com" <ryan.roberts@....com>,
	"shahuang@...hat.com" <shahuang@...hat.com>,
	"lpieralisi@...nel.org" <lpieralisi@...nel.org>,
	Aniket Agashe <aniketa@...dia.com>, Neo Jia <cjia@...dia.com>,
	Kirti Wankhede <kwankhede@...dia.com>,
	"Tarun Gupta (SW-GPU)" <targupta@...dia.com>,
	Vikram Sethi <vsethi@...dia.com>, Andy Currid <acurrid@...dia.com>,
	Alistair Popple <apopple@...dia.com>,
	John Hubbard <jhubbard@...dia.com>, Dan Williams <danw@...dia.com>,
	Zhi Wang <zhiw@...dia.com>, Matt Ochs <mochs@...dia.com>,
	Uday Dhoke <udhoke@...dia.com>, Dheeraj Nigam <dnigam@...dia.com>,
	"alex.williamson@...hat.com" <alex.williamson@...hat.com>,
	"sebastianene@...gle.com" <sebastianene@...gle.com>,
	"coltonlewis@...gle.com" <coltonlewis@...gle.com>,
	"kevin.tian@...el.com" <kevin.tian@...el.com>,
	"yi.l.liu@...el.com" <yi.l.liu@...el.com>,
	"ardb@...nel.org" <ardb@...nel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"gshan@...hat.com" <gshan@...hat.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 1/1] KVM: arm64: Allow cacheable stage 2 mapping using
 VMA flags

On Fri, Jan 17, 2025 at 06:52:39PM +0000, Catalin Marinas wrote:
> On Fri, Jan 17, 2025 at 10:00:50AM -0400, Jason Gunthorpe wrote:
> > On Thu, Jan 16, 2025 at 10:28:48PM +0000, Catalin Marinas wrote:
> > > with FEAT_MTE_PERM (patches from Aneesh on the list). Or, a bigger
> > > happen, disable MTE in guests (well, not that big, not many platforms
> > > supporting MTE, especially in the enterprise space).
> > 
> > As above, it seems we already effectively disable MTE in guests to use
> > VFIO.
> 
> That's fine. Once the NoTagAccess feature gets in, we could allow MTE
> here as well.

Yes, we can eventually mark these pages as NoTagAccess and maybe
someday consume a VMA flag from VFIO indicating that MTE works and
NoTagAccess is not required.

> I agree this is safe. My point was more generic about not allowing
> cacheable mappings without some sanity check. Ankit's patch relies on
> the pgprot used on the S1 mapping to make this decision. Presumably the
> pgprot is set by the host driver.

Yes, pgprot is set only by vfio, and pgprot == Normal is the sanity
check for KVM.

> > For this series it is only about mapping VMAs. Some future FD based
> > mapping for CC is going to also need similar metadata.. I have another
> > thread about that :)
> 
> How soon would you need that and if you come up with a different
> mechanism, shouldn't we unify them early rather than having two methods?

Looks to me like a year and half or more to negotiate this and
complete the required preperation patches. It is big and complex and
consensus is not obviously converging..

If we had a FD flow now I'd prefer to use it than going through the
VMA :(

I have a vauge hope that perhaps KVM could see the VMA when it creates
the memslot and then transparently pick up the FD under the VMA and
switch to a singular FD based mode inside KVM.

Jason