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: <9e1721a1-54a4-4007-a0f5-d651f5f21ae2@arm.com>
Date: Tue, 25 Feb 2025 13:00:40 +0000
From: Ryan Roberts <ryan.roberts@....com>
To: Mark Rutland <mark.rutland@....com>,
 Anshuman Khandual <anshuman.khandual@....com>
Cc: linux-arm-kernel@...ts.infradead.org,
 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 25/02/2025 12:32, Mark Rutland wrote:
> 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?

Not to my knowledge. For now the prototype code base is explicitly sticking to
48-bit PA and 44-bit VA (for initial simplicitly because that's the limit for 4
levels).

> 
>> 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.

Yeah, agreed. This was initially just a hack I did to get things working.

> 
> 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
>>
>>