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: <20250115143213.GQ5556@nvidia.com>
Date: Wed, 15 Jan 2025 10:32:13 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Ankit Agrawal <ankita@...dia.com>
Cc: David Hildenbrand <david@...hat.com>, "maz@...nel.org" <maz@...nel.org>,
	"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>,
	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>,
	"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>,
	"kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"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 v2 1/1] KVM: arm64: Allow cacheable stage 2 mapping using
 VMA flags

On Tue, Jan 14, 2025 at 11:13:48PM +0000, Ankit Agrawal wrote:
> > Do we really want another weirdly defined VMA flag? I'd really like to
> > avoid this.. 
> 
> I'd let Catalin chime in on this. My take of the reason for his suggestion is
> that we want to reduce the affected configs to only the NVIDIA grace based
> systems. The nvgrace-gpu module would be setting the flag and the
> new codepath will only be applicable there. Or am I missing something here?

We cannot add VMA flags that are not clearly defined. The rules for
when the VMA creater should set the flag need to be extermely clear
and well defined.

> > Can't we do a "this is a weird VM_PFNMAP thing, let's consult the VMA
> > prot + whatever PFN information to find out if it is weird-device and
> > how we could safely map it?"
> 
> My understanding was that the new suggested flag VM_FORCE_CACHED
> was essentially to represent "whatever PFN information to find out if it is
> weird-device". Is there an alternate reliable check to figure this out?

For instance FORCE_CACHED makes no sense, how will the VMA creator
know it should set this flag?

> Currently in the patch we check the following. So Jason, is the suggestion that
> we simply return error to forbid such condition if VM_PFNMAP is set?
> +	else if (!mte_allowed && kvm_has_mte(kvm))

I really don't know enought about mte, but I would take the position
that VM_PFNMAP does not support MTE, and maybe it is even any VMA
without VM_MTE/_ALLOWED does not support MTE?

At least it makes alost more sense for the VMA creator to indicate
positively that the underlying HW supports MTE.

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ