linux-kernel - Re: [PATCH v3 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID:
 <SA1PR12MB71992BC382DA4ED506100590B088A@SA1PR12MB7199.namprd12.prod.outlook.com>
Date: Wed, 7 May 2025 15:26:05 +0000
From: Ankit Agrawal <ankita@...dia.com>
To: Jason Gunthorpe <jgg@...dia.com>, Catalin Marinas
	<catalin.marinas@....com>
CC: Oliver Upton <oliver.upton@...ux.dev>, Sean Christopherson
	<seanjc@...gle.com>, Marc Zyngier <maz@...nel.org>, "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>, "david@...hat.com" <david@...hat.com>, 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>,
	Krishnakant Jaju <kjaju@...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>,
	"ddutile@...hat.com" <ddutile@...hat.com>, "tabba@...gle.com"
	<tabba@...gle.com>, "qperret@...gle.com" <qperret@...gle.com>,
	"kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
	"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 v3 1/1] KVM: arm64: Allow cacheable stage 2 mapping using
 VMA flags

>> Unless FWB implies CTR_EL0.DIC (AFAIK, it doesn't) we may be
>> restricting some CPUs.
>
> Yes, it will further narrow the CPUs down.
> 
> However, we just did this discussion for BBML2 + SMMUv3 SVA. I think
> the same argument holds. If someone is crazy enough to build a CPU
> with CXLish support and uses an old core without DIC, IDC and S2FWB
> then they are going to have a bunch of work to fix the SW to support
> it. Right now we know of no system that exists like this..
>
> Jason

Catalin, do you agree if I can go ahead and add the check for
ARM64_HAS_CACHE_DIC?

>> Another CAP for executable PFNMAP then?
>
> IDK, either that or a more general cap 'support PFNMAP VMAs'?

I think it would be good to have the generic cap that is safe for
executable as well.


>> However it appears that the memslot flag isn't a must-have. The memslot
>> flag cannot influence the KVM code anyways. For FWB, the PFNMAP would
>> be cacheable and userspace should just assume S2FWB behavior; it would
>> be a security bug otherwise as Jason pointed earlier (S1 cacheable,
>> S2 noncacheable). For !FWB, a cacheable PFNMAP could not be allowed
>> and VMM shouldn't attempt to create memslot at all by referring the cap.
...
>> 2. Enable support for cacheable PFN maps if S2FWB is enabled by following
>> the vma pgprot (this patch).
>> 3. Add and expose the new KVM cap to expose cacheable PFNMAP (set to false
>> for !FWB).
>
> I'll defer the memslot flag decision to the KVM maintainers. If we had
> one, it will enforce (2) or reject it as per (1) depending on the S1
> attributes.

Marc, Oliver, let me know your thoughts if we should add memslot flag and I'll
implement accordingly.