Re: [PATCH RFC v10 20/22] arm64: kpkeys: Enable kpkeys_hardened_pgtables support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [High] arm64: mm: preserved pkey in trans_pgd_create_copy() faults on
  kexec/hibernate
- [Medium] mm: kpkeys: redundant KASAN shadow walks in
  protect_early_kernel_pgtables()
--

commit 974504a027662a7ee9def760c6976edfcfbc634c
Author: Kevin Brodsky <kevin.brodsky@arm.com>

arm64: kpkeys: Enable kpkeys_hardened_pgtables support

This commit selects ARCH_HAS_KPKEYS_HARDENED_PGTABLES under ARM64_POE to
enable kpkeys_hardened_pgtables support on arm64.

> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index f7e4ffbc07ac2..28023dd0fd4b0 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -2301,6 +2301,7 @@ config ARM64_POE
>  	select ARCH_USES_HIGH_VMA_FLAGS
>  	select ARCH_HAS_PKEYS
>  	select ARCH_HAS_KPKEYS
> +	select ARCH_HAS_KPKEYS_HARDENED_PGTABLES

[Severity: High]
Does enabling CONFIG_KPKEYS_HARDENED_PGTABLES cause hibernation resume and
kexec relocation to fault when writing through the transitional linear map?

When kpkeys_hardened_pgtables is active, linear-map PTEs for page table
pages carry KPKEYS_PKEY_PGTABLES, which is read-only under POR_EL1_INIT.
Both swsusp_arch_resume() and machine_kexec_post_load() call
trans_pgd_create_copy() to build a writable copy of the linear map so
swsusp_arch_suspend_exit() and arm64_relocate_new_kernel() can overwrite
existing kernel memory, including page tables:

arch/arm64/mm/trans_pgd.c:copy_pte() {
	...
		__set_pte(dst_ptep, pte_mkvalid_k(pte_mkwrite_novma(pte)));
	...
}

Neither pte_mkwrite_novma() nor pte_mkvalid_k() clears PTE_PO_IDX_MASK, and
POR_EL1 remains set to POR_EL1_INIT during the copy.  Any store in
swsusp_arch_suspend_exit() or arm64_relocate_new_kernel() to a destination
page that was a page table when trans_pgd_create_copy() ran will trigger a
fatal synchronous EL1 Permission Overlay fault with DAIF masked.  Clearing
PTE_PO_IDX_MASK (or setting the default pkey) in copy_pte() would avoid
preserving the read-only overlay in the transitional page tables.

[Severity: Medium]
Can protect_early_kernel_pgtables() hang or trigger a soft lockup at boot
when KASAN or runtime-folded LPA2 is enabled?

On arm64 with CONFIG_KASAN_GENERIC or CONFIG_KASAN_SW_TAGS,
kasan_init_shadow() populates multi-terabyte shadow regions before
mm_core_init() using the shared kasan_early_shadow_{p4d,pud,pmd,pte} tables.
When kpkeys_hardened_pgtables_init() calls protect_early_kernel_pgtables(),
walk_kernel_page_table_range(PAGE_OFFSET, ULONG_MAX, ...) does not skip
these shared KASAN tables, so protect_pte_table() calls
set_direct_map_pkey() and broadcasts a TLB invalidation on the same
kasan_early_shadow_pte page for every 2 MiB PMD slot across the shadow
range.

In addition, when CONFIG_ARM64_VA_BITS_52 is enabled on hardware that falls
back to 48-bit or 47-bit VA at runtime, PAGE_OFFSET is _PAGE_OFFSET(52)
rather than _PAGE_OFFSET(vabits_actual).  Because pgd_none() returns false
when folded and pgd_to_folded_p4d() / p4d_to_folded_pud() aligns down to the
start of swapper_pg_dir, walking from PAGE_OFFSET re-walks and flushes the
entire swapper_pg_dir 16 times on 4K pages or 32 times on 16K pages.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261109-kpkeys-v10-0-aa6c4d9603bc@arm.com?part=20