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: <20250331144437.GE10839@nvidia.com>
Date: Mon, 31 Mar 2025 11:44:37 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Oliver Upton <oliver.upton@...ux.dev>
Cc: Sean Christopherson <seanjc@...gle.com>, Marc Zyngier <maz@...nel.org>,
	Ankit Agrawal <ankita@...dia.com>,
	Catalin Marinas <catalin.marinas@....com>,
	"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 Wed, Mar 26, 2025 at 11:51:57AM -0700, Oliver Upton wrote:
> 
>  1) If struct page memory, use a cacheable mapping. CMO for non-FWB.
> 
>  2) If cacheable PFNMAP:
>    a) With FWB, use a cacheable mapping
>    b) Without FWB, fail.
> 
>  3) If VM_ALLOW_ANY_UNCACHED, use Normal Non-Cacheable mapping
> 
>  4) Otherwise, Device-nGnRE
> 
> I understand 2b breaks ABI, but the 'typical' VFIO usages fall into (3)
> and (4).

+1 (and +1 to Sean's remark about strictly tracking the VMA as well)

IMHO not doing 2b is a "security" bug today. Catalin suggested we fix
it as a first step to get agreement on this assement and fix. Once
fixed there is no way for KVM to create a S2 with cachable semantics
different from the VMA, or to have missing CMOs.

That simplifies the discussion of adding 2a to strictly track
cachable.

I also don't see a need for a flag here.

> A pedantic but correct live migration / snapshotting implementation
> on non-FWB would need to do CMOs in case the VM used a non-WB
> mapping for memory.

>From a live migration perspecive, we have already built in a lot of
things on the VFIO side where a live migration can be attempted and
then fail because of late-detected HW incompatibilities. We've sort of
punted this for now to the orchestrator and operator. There is an
expectation the environment will somehow ensure that live migration
machine pools are sufficiently uniform when using VFIO. It is much
more restricted than normal no-VFIO VM live migration.

Given you can't have VM live migration of MMIO backed Cachable memory
without a VFIO live migration driver, I wouldn't worry too much about
these fine details from the KVM side. If /proc/cpuinfo shows the FWB
that would be approximately similar discoverability to all the other
limitations.

Jason