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: <aBDTpu_ACoXAPoE2@arm.com>
Date: Tue, 29 Apr 2025 14:27:02 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: Ankit Agrawal <ankita@...dia.com>
Cc: Jason Gunthorpe <jgg@...dia.com>, 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

On Tue, Apr 29, 2025 at 10:47:58AM +0000, Ankit Agrawal wrote:
> >> 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()).

I forgot the details here. I think it makes sense in general but as the
first patch, we currently block cacheable PFNMAP anyway. Probably what
you meant already but - this patch should block the PFNMAP slot if
there's a cacheable S1 alias.

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

Without the memslot flag, I assume at least the VMM will have to enable
KVM_CAP_ARM_WB_PFNMAP (or whatever it will be called) to get the new
behaviour.

BTW, we should reject exec mappings as well (they probably fail for S1
VFIO since set_pte_at() will try to do cache maintenance).

-- 
Catalin