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:
 <SA1PR12MB7199500A3683B15A64B663D6B0D12@SA1PR12MB7199.namprd12.prod.outlook.com>
Date: Tue, 11 Mar 2025 12:07:20 +0000
From: Ankit Agrawal <ankita@...dia.com>
To: Marc Zyngier <maz@...nel.org>
CC: Jason Gunthorpe <jgg@...dia.com>, "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>, "catalin.marinas@....com" <catalin.marinas@....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>,
	"seanjc@...gle.com" <seanjc@...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

Thanks Marc for the feedback.

> No, I'm concerned that a well established API (populating a memslot)
> works in some case and doesn't work in another without a clear
> indication of *why* we have this behaviour.
>
> To me, this indicates that userspace needs to buy in this new
> behaviour, and that behaviour needs to be advertised by a capability,
> which is in turn conditional on FWB.

Yes, that makes sense.

>>> Perhaps we can gracefully fall back to the default device mapping
>>> in such case? But that would cause VM to crash as soon as it makes some
>>> access violating DEVICE_nGnRE.
>
> Which would now be a regression...
> 
> My take is that this cacheable PNFMAP contraption must only be exposed
> to a guest if FWB is available. We can't prevent someone to do an
> mmap() behind our back, but we can at least:
>
> - tell userspace whether this is supported

For my education, what is an accepted way to communicate this? Please let
me know if there are any relevant examples that you may be aware of.

I suppose just checking for FWB (for PFNMAP) and returning some sort of
an error on userspace mmap will not be enough of a hint here?

> - only handle the fault if userspace has bought in this mode
> - report the fault to userspace for it to fix things otherwise
>
>        M.
>
> --
> Without deviation from the norm, progress is not possible.