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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID:
 <SA1PR12MB71996988916E1FB15149DD13B0802@SA1PR12MB7199.namprd12.prod.outlook.com>
Date: Tue, 29 Apr 2025 10:47:58 +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

>> In this case KVM still needs to know the properties of the device. Not
>> sure how it could best do this without a vma.
>
> Well, the idea I hope to succeed with would annotate this kind of
> information inside the page list that would be exchanged through the
> FD.
>
> There is an monstrous thread here about this topic:
>
>
>
> https://lore.kernel.org/all/20250107142719.179636-1-yilun.xu@linux.intel.com/
>
> I can't find it in the huge thread but I did explain some thoughts on
> how it could work
>
> Jason

Hi,

Based on the recent discussions, I gather that having a KVM_CAP
to expose the support for cacheable PFNMAP to the VMM would be
useful from VM migration point of view.

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.

Also, can we take the fd based communication path between VFIO
and KVM separately?

I am planning to send out the series with the following implementation.
Please let me know if there are any disagreements or concerns.

1. Block cacheable PFN map in memslot creation (kvm_arch_prepare_memory_region)
and during fault handling (user_mem_abort()).
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).