linux-kernel - Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping

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: <ee2bf4ba-0121-44dc-a465-4c186dc18f19@arm.com>
Date: Wed, 21 Jan 2026 10:20:52 +0000
From: Ryan Roberts <ryan.roberts@....com>
To: Yeoreum Yun <yeoreum.yun@....com>, Yang Shi <yang@...amperecomputing.com>
Cc: Will Deacon <will@...nel.org>, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org, linux-rt-devel@...ts.linux.dev,
 catalin.marinas@....com, akpm@...ux-oundation.org, david@...nel.org,
 kevin.brodsky@....com, quic_zhenhuah@...cinc.com, dev.jain@....com,
 chaitanyas.prakash@....com, bigeasy@...utronix.de, clrkwllms@...nel.org,
 rostedt@...dmis.org, lorenzo.stoakes@...cle.com, ardb@...nel.org,
 jackmanb@...gle.com, vbabka@...e.cz, mhocko@...e.com
Subject: Re: [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting
 the linear mapping

On 21/01/2026 08:32, Yeoreum Yun wrote:
>>>> My concern is that if a secondary CPU can race and cause a split, that is
>>>> unsound because we have determined that although the primary CPU supports BBML2,
>>>> at least one of the secondary CPUs does not. So splitting a live mapping is unsafe.
>>>>
>>>> I just had a brief chat with Rutland, and he agrees that this _could_ be a
>>>> problem. Basically there is a window between onlining the secondary cpus and
>>>> entering the stop_machine() where one of those cpus _could_ end up doing
>>>> something that causes us to split the linear map.
>>
>> If I remember correctly, split_kernel_leaf_mapping() does call
>> system_supports_bbml2_noabort() before doing real split. So we basically
>> should fall into two categories:
>>
>> 1. bbml2_noabort is supported on all cpus. Everything is fine.
>> 2. bbml2_noabort is not supported on all cpus. split_kernel_leaf_mapping()
>> just returns 0. Kernel doesn't split page table, so there won't be TLB
>> conflict issue. But the following page prot update may see unexpected block
>> mapping, then a   WARN  will be raised and it will return -EINVAL. So the
>> worst case is the caller will fail (IIRC all the callers of set_memory_*()
>> handle the failure), and we can know who is trying to change linear mapping
>> before the linear mapping gets                    finalized. AFAICT I
>> haven't seen such WARN yet.

Ahh good point! So this isn't quite as terrible as I was thinking.

> 
> Thanks for the great detail :)
> I've missed system_supports_bbml2_noabort() in split_kernel_leaf_mapping().
> 
>>
>>>>
>>>> I'm not immediately sure how to solve that.
>>
>> Do we need some synchronization mechanism? If the linear mapping is not
>> finalized yet, split_kernel_leaf_mapping() will spin. For example, something
>> like this off the top of my head,
>>
>> DEFINE_STATIC_KEY_FALSE(linear_mapping_finalized);
>>
>> Once the linear mapping is finalized, we can call
>> static_branch_enable(&linear_mapping_finalized);
>>
>> In split_kernel_leaf_mapping(), we can just do:
>>
>> retry:
>>     if (!static_branch_likely(&linear_mapping_finalized))
>>         goto retry;
>>

Yuck... But I guess it might work as long as the primary thread never does
anything that would cause an attempt to split; otherwise we have a deadlock.

>>
>> There may be better way to handle it. But this case should be very unlikely
>> IMHO. It sounds crazy to have such complicated kernel threads run so early.
>> I'm not sure whether we should pay immediate attention to it or not.

I think we need to figure out if this is actually possible. We bring up the
secondary cpus, set system caps and finalize the linear map in smp_init().
That's called from kernel_init_freeable() which is called from kernel_init(),
which is invoked as a thread pinned to the boot cpu.

sched_init_smp() is called after smp_init() (i.e. after the linear map is
finalized). I'm guessing (based on the name of sched_init_smp()) that nothing
other than the idle thread will run on any secondaries until after
sched_init_smp() is called? (I'd be greatful if anyone can confirm that).

Rutland suggested that it's probably too early for any PM type stuff to be
running in the idle loop, so based on all of that, perhaps this is not a problem
after all and there is basically zero chance of a secondary cpu doing anything
that could cause a linear map split during this window?

I'm inclined to leave this as is for now.

Thanks,
Ryan

> 
> Thinking about it again, I’m not sure whether
> it is acceptable to use a sleepable synchronization mechanism at this stage,
> like split_kernel_leaf_mapping() does with mutex_lock()
> (even though it may be technically possible).
> It also feels odd that this function can be called at this point in time.
> 
> If this is indeed considered problematic,
> I think it would be better to simply return -EINVAL immediately
> when linear_mapping_finalized has not yet been completed.
> 
> --
> Sincerely,
> Yeoreum Yun