linux-kernel - Re: [RFC PATCH v6 3/4] arm64: mm: support large block mapping when rodata=full

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: <aLCkd-E1wgszoZKd@arm.com>
Date: Thu, 28 Aug 2025 19:48:23 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: Ryan Roberts <ryan.roberts@....com>
Cc: Yang Shi <yang@...amperecomputing.com>, will@...nel.org,
	akpm@...ux-foundation.org, Miko.Lenczewski@....com,
	dev.jain@....com, scott@...amperecomputing.com, cl@...two.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v6 3/4] arm64: mm: support large block mapping when
 rodata=full

On Thu, Aug 28, 2025 at 06:45:32PM +0100, Ryan Roberts wrote:
> On 28/08/2025 18:09, Catalin Marinas wrote:
> > On Tue, Aug 05, 2025 at 09:13:48AM +0100, Ryan Roberts wrote:
> >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> >> index abd9725796e9..f6cd79287024 100644
> >> --- a/arch/arm64/mm/mmu.c
> >> +++ b/arch/arm64/mm/mmu.c
> > [...]
> >> @@ -640,6 +857,16 @@ static inline void arm64_kfence_map_pool(phys_addr_t kfence_pool, pgd_t *pgdp) {
> >>  
> >>  #endif /* CONFIG_KFENCE */
> >>  
> >> +static inline bool force_pte_mapping(void)
> >> +{
> >> +	bool bbml2 = system_capabilities_finalized() ?
> >> +		system_supports_bbml2_noabort() : bbml2_noabort_available();
> >> +
> >> +	return (!bbml2 && (rodata_full || arm64_kfence_can_set_direct_map() ||
> >> +			   is_realm_world())) ||
> >> +		debug_pagealloc_enabled();
> >> +}
> >> +
> >>  static void __init map_mem(pgd_t *pgdp)
> >>  {
> >>  	static const u64 direct_map_end = _PAGE_END(VA_BITS_MIN);
> >> @@ -665,7 +892,7 @@ static void __init map_mem(pgd_t *pgdp)
> >>  
> >>  	early_kfence_pool = arm64_kfence_alloc_pool();
> >>  
> >> -	if (can_set_direct_map())
> >> +	if (force_pte_mapping())
> >>  		flags |= NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
> >>  
> >>  	/*
> >> @@ -1367,7 +1594,7 @@ int arch_add_memory(int nid, u64 start, u64 size,
> >>  
> >>  	VM_BUG_ON(!mhp_range_allowed(start, size, true));
> >>  
> >> -	if (can_set_direct_map())
> >> +	if (force_pte_mapping())
> >>  		flags |= NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
> >>  
> >>  	__create_pgd_mapping(swapper_pg_dir, start, __phys_to_virt(start),
> > 
> > Not sure this works in a heterogeneous configuration.
> > bbml2_noabort_available() only checks the current/boot CPU which may
> > return true but if secondary CPUs don't have the feature, it results in
> > system_supports_bbml2_noabort() being false with force_pte_mapping()
> > also false in the early map_mem() calls.
> 
> The intent is that we eagerly create a block-mapped linear map at boot if the
> boot CPU supports BBML2. If, once we have determined that a secondary CPU
> doesn't support BBML2 (and therefore the system doesn't support it) then we
> repaint the linear map using page mappings.
> 
> The repainting mechanism is added in the next patch.

Ah, I haven't reached that patch yet ;).

> I've tested this with heterogeneous configs and I'm confident it does work.

Great. The downside is that such configuration is rare, the logic is
fairly complex and won't get tested much. Hardware with such
configuration will take a slight hit on the boot time.

I don't remember the discussions around Miko's patches adding the BBML2
feature - do we have such heterogeneous configurations or are they just
theoretical at this stage?

> FYI, I actually have a new version of this ready to go - I was hoping to post
> tomorrow, subject to performance results. I thought you were implying in a
> previous mail that you weren't interested in reviewing until it was based on top
> of an -rc. Perhaps I misunderstood. Let me know if you want me to hold off on
> posting that given you are now reviewing this version.

In general I prefer patches on top of a fixed -rc, especially if I need
to apply them locally. But I was wondering if you are waiting for review
feedback before rebasing, so I had a quick look ;).

Please post a new version. I'll have a look at that since you were
planning to update a few bits anyway.

-- 
Catalin