linux-kernel - Re: [PATCH V2] arm64/mm: Implement pte_po

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: <20250509150232.GA5984@willie-the-truck>
Date: Fri, 9 May 2025 16:02:33 +0100
From: Will Deacon <will@...nel.org>
To: Anshuman Khandual <anshuman.khandual@....com>
Cc: Ryan Roberts <ryan.roberts@....com>,
	linux-arm-kernel@...ts.infradead.org,
	Catalin Marinas <catalin.marinas@....com>,
	Marc Zyngier <maz@...nel.org>, kvmarm@...ts.linux.dev,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2] arm64/mm: Implement pte_po_index() for permission
 overlay index

On Mon, May 05, 2025 at 02:20:46PM +0530, Anshuman Khandual wrote:
> 
> 
> On 4/29/25 22:15, Ryan Roberts wrote:
> > On 29/04/2025 16:11, Will Deacon wrote:
> >> On Tue, Apr 15, 2025 at 11:14:42AM +0530, Anshuman Khandual wrote:
> >>> From: Ryan Roberts <ryan.roberts@....com>
> >>>
> >>> Previously pte_access_permitted() used FIELD_GET() directly to retrieve
> >>> the permission overlay index from the pte. However, FIELD_GET() doesn't
> >>> work for 128 bit quanitites. Since we are about to add support for D128
> >>> pgtables, let's create a specific helper, pte_po_index() which can do
> >>> the required mask and shift regardless of the data type width.
> >>
> >> You say:
> >>
> >> "we are about to add support for D128 pgtables"
> > 
> > Providing some context: Anshuman has a private branch that adds D128 pgtable
> > support to the kernel (it does not yet do this for KVM). I originally created
> > this patch to fix a bug on that branch, so the "we are about to add ..." comment
> > really only makes sense in that context.
> > 
> > We are not yet ready to post D128 upstream - there are still a lot of questions
> > to answer - but Anshuman has been posting some of the reshuffling and cleanups
> > that prepare the way for D128 where (we think) it makes sense. The aim is to
> > reduce the diff as much as we can.
> 
> Agreed. All these patches have been really harmless clean ups and re-orgs etc,
> that do not affect existing 64 bit page table management or its functioning in
> any manner. OTOH these changes help the kernel prepare for D128 enablement.

In this case, I wouldn't call it harmless clean-up. You're actively
removing the use of helper macros which is inevitably going to result in
churn.

Please teach FIELD_GET() to work with 128-bit types instead.

Will