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] [day] [month] [year] [list]
Message-ID:
 <SA1PR12MB719976799AD7F9FC4407A5A9B0BD2@SA1PR12MB7199.namprd12.prod.outlook.com>
Date: Wed, 16 Apr 2025 08:51:05 +0000
From: Ankit Agrawal <ankita@...dia.com>
To: Sean Christopherson <seanjc@...gle.com>, Jason Gunthorpe <jgg@...dia.com>
CC: Marc Zyngier <maz@...nel.org>, Catalin Marinas <catalin.marinas@....com>,
	Oliver Upton <oliver.upton@...ux.dev>, "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

Hi, summarizing the discussion so far and outlining the next steps. The key points
are as follows:
1. KVM cap to expose whether the kernel supports mapping cacheable PFNMAP:
If the host doesn't have FWB, then the capability doesn't exist. Jason, Oliver, Caitlin
and Sean points that this may not be required as userspace do not have
much choice anyways. KVM has to follow the PTEs and userspace cannot ask
for something different. However, Marc points that enumerating FWB support
would allow userspace to discover the support and prevent live-migration
across FWB and non-FWB hosts. Jason suggested that this may still be fine as
we have already built in VFIO side protection where a live migration can be
attempted and then fail because of late-detected HW incompatibilities.

2. New memslot flag that VMM passes at memslot registration:
Discussion point that this is not necessary and KVM should just follow the
VMA pgprot.

3. Fallback path handling for PFNMAP when the FWB is not set:
Discussion points that there shouldn't be any fallback path and the memslot
should just fail. i.e. KVM should not allow degrading cachable to non-cachable
when it can't do flushing. This is to prevent the potential security issue
pointed by Jason (S1 cacheable, S2 noncacheable).


So AIU, the next step is to send out the updated series with the following patches:
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), pending maintainers' feedback on the necessity of this capability.

Please let me know if there are any inaccuracies.

Thanks
Ankit Agrawal


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ