Re: [PATCH RFC v10 19/22] arm64: kpkeys: Batch KPKEYS_CTX_PGTABLES switches

[Kevin Brodsky <kevin.brodsky@arm.com>]

On 10/11/2026 17:02, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue to consider:
> - [Medium] arm64: kpkeys: POR_EL1 desync with is_lazy_mmu_mode_active()
>   on entry/exit
> --
>
> commit 1b260fb8242fe345fd5e4bdc00ba9a4272383991
> Author: Kevin Brodsky <kevin.brodsky@arm.com>
>
> arm64: kpkeys: Batch KPKEYS_CTX_PGTABLES switches
>
> This commit batches KPKEYS_CTX_PGTABLES context switches across lazy MMU
> sections by switching POR_EL1 when entering and leaving lazy MMU mode and
> skipping per-write guard switches while lazy MMU mode is active.
>
>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>> index 5f46d4cb38828..5e958531e6abe 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -43,10 +43,44 @@
>>  
>>  #ifdef CONFIG_KPKEYS_HARDENED_PGTABLES
>>  KPKEYS_GUARD_COND(kpkeys_hardened_pgtables, KPKEYS_CTX_PGTABLES,
>> -		  kpkeys_hardened_pgtables_enabled())
>> -#else
>> +		  kpkeys_hardened_pgtables_enabled() &&
>> +		  !is_lazy_mmu_mode_active())
>> +
>> +static inline void kpkeys_lazy_mmu_enter(void)
>> +{
>> +	if (!kpkeys_hardened_pgtables_enabled())
>> +		return;
>> +
>> +	current->thread.kpkeys_state_lazy_mmu =
>> +		kpkeys_enter_context(KPKEYS_CTX_PGTABLES);
>> +}
> [Severity: Medium]
> Can a synchronous exception between updating current->lazy_mmu_state and
> switching SYS_POR_EL1 cause a fatal permission fault when writing to page
> tables?

Sashiko already reported this on RFC v9. What I concluded is that this
is very unlikely - we shouldn't get a (non-fatal) synchronous exception
in that window. The one plausible case is kprobes, and I guess the
answer to that one is: don't put a kprobe there :) (We can't easily
enforce this though as NOKPROBE_SYMBOL() doesn't work for inlined
functions.)

A more serious concern is that since RFC v7, POR_EL1 is no longer reset
on exception entry, because that doesn't play well with lazy MMU mode
either [1]. If we found a way for lazy MMU mode to be fully disabled
while exceptions are handled, then it should address both concerns at
the same time.

- Kevin

[1]
https://lore.kernel.org/linux-hardening/7dc9485d-a822-494d-9384-4a973c782c11@arm.com/

> lazy_mmu_mode_enable() and __task_lazy_mmu_mode_resume() mark
> current->lazy_mmu_state active before calling arch_enter_lazy_mmu_mode():
>
> include/linux/pgtable.h:lazy_mmu_mode_enable() {
>     ...
> 	if (state->enable_count++ == 0)
> 		arch_enter_lazy_mmu_mode();
> }
>
> On arm64, synchronous kernel exceptions (such as kprobes or KFENCE page
> faults) do not set NMI, hardirq, or softirq bits in preempt_count(), so
> in_interrupt() remains false and is_lazy_mmu_mode_active() returns true:
>
> lazy_mmu_mode_enable()
>   state->enable_count++ (0 -> 1)
>   <synchronous exception, e.g. kprobe / KFENCE fault>
>     ...
>       __set_pte_nosync()
>         guard(kpkeys_hardened_pgtables)()
>           is_lazy_mmu_mode_active() == true  <-- skips POR_EL1 switch
>         WRITE_ONCE(*ptep, pte)               <-- unhandled EL1 permission fault
>   arch_enter_lazy_mmu_mode()
>     kpkeys_lazy_mmu_enter()
>
> Because is_lazy_mmu_mode_active() is already true while SYS_POR_EL1 still
> maps KPKEYS_PKEY_PGTABLES as read-only, both a nested
> lazy_mmu_mode_enable() and guard(kpkeys_hardened_pgtables)() skip
> switching SYS_POR_EL1, and the page table write faults.
>
> A symmetric window exists in lazy_mmu_mode_disable() and
> __task_lazy_mmu_mode_pause(), where enable_count or pause_count is updated
> before arch_leave_lazy_mmu_mode() restores SYS_POR_EL1.  A synchronous
> exception in that window that enters a nested lazy_mmu_mode_enable() sees
> SYS_POR_EL1 already set to KPKEYS_CTX_PGTABLES and overwrites
> kpkeys_state_lazy_mmu.entered_context with false, causing the outer
> kpkeys_lazy_mmu_exit() to leave SYS_POR_EL1 writable.