linux-kernel - Re: [PATCH] arm64/mm: Explicit cast conversions to correct data type

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: <Z724Q1ofM1GvKquV@J2N7QTR9R3>
Date: Tue, 25 Feb 2025 12:32:03 +0000
From: Mark Rutland <mark.rutland@....com>
To: Anshuman Khandual <anshuman.khandual@....com>
Cc: linux-arm-kernel@...ts.infradead.org,
	Ryan Roberts <ryan.roberts@....com>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64/mm: Explicit cast conversions to correct data type

On Wed, Feb 19, 2025 at 09:26:46AM +0530, Anshuman Khandual wrote:
> From: Ryan Roberts <ryan.roberts@....com>
> 
> When CONFIG_ARM64_PA_BITS_52 is enabled, page table helpers __pte_to_phys()
> and __phys_to_pte_val() are functions which return phys_addr_t and pteval_t
> respectively as expected. But otherwise without this config being enabled,
> they are defined as macros and their return types are implicit.
> 
> Until now this has worked out correctly as both pte_t and phys_addr_t data
> types have been 64 bits. But with the introduction of 128 bit page tables,
> pte_t becomes 128 bits. Hence this ends up with incorrect widths after the
> conversions, which leads to compiler warnings.

Does 128-bit page table not imply 52-bit PAs?

> Fix the warnings by explicitly casting to the correct type after doing the
> conversion.

I think it would be simpler and clearer if we replaced the macros with
functions, such that __pte_to_phys() and __phys_to_pte_val() are
*always* functions.

That way it's easier to compar the CONFIG_ARM64_PA_BITS_52=y and
CONFIG_ARM64_PA_BITS_52=n versions, and the types are always explciit
for inputs and outputs, so there'd be less room for error and the
compiler can warn us of type safety issues in any configuration.

That and we can delete the comment block immediately above at the same
time.

Mark.

> Cc: Catalin Marinas <catalin.marinas@....com>
> Cc: Will Deacon <will@...nel.org>
> Cc: linux-arm-kernel@...ts.infradead.org
> Cc: linux-kernel@...r.kernel.org
> Signed-off-by: Ryan Roberts <ryan.roberts@....com>
> Signed-off-by: Anshuman Khandual <anshuman.khandual@....com>
> ---
> This patch applies on v6.14-rc3
> 
>  arch/arm64/include/asm/pgtable.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 0b2a2ad1b9e8..1da2421c9a15 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -84,8 +84,8 @@ static inline pteval_t __phys_to_pte_val(phys_addr_t phys)
>  	return (phys | (phys >> PTE_ADDR_HIGH_SHIFT)) & PHYS_TO_PTE_ADDR_MASK;
>  }
>  #else
> -#define __pte_to_phys(pte)	(pte_val(pte) & PTE_ADDR_LOW)
> -#define __phys_to_pte_val(phys)	(phys)
> +#define __pte_to_phys(pte)	((phys_addr_t)(pte_val(pte) & PTE_ADDR_LOW))
> +#define __phys_to_pte_val(phys)	((pteval_t)(phys))
>  #endif
>  
>  #define pte_pfn(pte)		(__pte_to_phys(pte) >> PAGE_SHIFT)
> -- 
> 2.25.1
> 
>