From: Catalin Marinas <catalin.marinas@arm.com>
To: Ard Biesheuvel <ardb+git@google.com>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, will@kernel.org,
mark.rutland@arm.com, Ard Biesheuvel <ardb@kernel.org>,
Ryan Roberts <ryan.roberts@arm.com>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Liz Prucka <lizprucka@google.com>,
Seth Jenkins <sethjenkins@google.com>,
Kees Cook <kees@kernel.org>,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH v3 07/13] arm64: mm: Use hierarchical XN mapping for the fixmap
Date: Wed, 8 Apr 2026 16:45:50 +0100 [thread overview]
Message-ID: <adZ4LpvJJz-3K20O@arm.com> (raw)
In-Reply-To: <20260320145934.2349881-22-ardb+git@google.com>
On Fri, Mar 20, 2026 at 03:59:42PM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> Nothing in the fixmap or in its vicinity requires executable
> permissions, and given that it is placed at exactly 1 GiB from the end
> of the virtual address space, we can safely set the hierarchical XN
> attributes on the level 2 table entries covering the fixmap, without
> running the risk of inadvertently taking away the executable permissions
> on an adjacent mappings.
>
> This is a hardening measure that reduces the risk of the fixmap being
> abused to create executable mappings in the kernel address space.
>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> arch/arm64/mm/fixmap.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
> index c5c5425791da..c3dd3c868cf5 100644
> --- a/arch/arm64/mm/fixmap.c
> +++ b/arch/arm64/mm/fixmap.c
> @@ -48,7 +48,8 @@ static void __init early_fixmap_init_pte(pmd_t *pmdp, unsigned long addr)
> if (pmd_none(pmd)) {
> ptep = bm_pte[BM_PTE_TABLE_IDX(addr)];
> __pmd_populate(pmdp, __pa_symbol(ptep),
> - PMD_TYPE_TABLE | PMD_TABLE_AF);
> + PMD_TYPE_TABLE | PMD_TABLE_AF |
> + PMD_TABLE_PXN | PMD_TABLE_UXN);
> }
> }
Sashiko reckons this breaks kpti. I think that's valid but I couldn't
reproduce it on qemu (maybe it doesn't implement hierarchical
permissions). Then I tried FVP and the whole series panics (unrelated to
kpti). With kvm-arm.mode=protected, I think kvm_ksym_ref() is lm_alias()
and we have kvm_hyp_init_symbols() trying to flush the bss.
I'll drop it for now.
Unable to handle kernel paging request at virtual address fff00000748f7000
Mem abort info:
ESR = 0x0000000096000147
** replaying previous printk message **
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x07: level 3 translation fault
Data abort info:
ISV = 0, ISS = 0x00000147, ISS2 = 0x00000000
CM = 1, WnR = 1, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
swapper pgtable: 4k pages, 52-bit VAs, pgdp=00000000f40ad000
[fff00000748f7000] pgd=18000008fffff403, p4d=18000008ffffe403, pud=18000008ffffd403, pmd=18000008fffe9403, pte=00e80000f48f7406
Internal error: Oops: 0000000096000147 [#1] SMP
Modules linked in:
CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc3-00013-g6bb20b972b8c #2 PREEMPT
Hardware name: FVP Base RevC (DT)
pstate: 81400005 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
pc : dcache_clean_inval_poc+0x24/0x48
lr : kvm_arm_init+0xb48/0x1338
sp : ffff80008005bd20
x29: ffff80008005bd60 x28: ffff95c63230b000 x27: 0000000000000004
x26: 0000000000000001 x25: ffff95c631a160c0 x24: 0000000000000008
x23: 0000000000000000 x22: 0000000000000000 x21: fff00000748f7000
x20: 0000000000002000 x19: 0001101131111112 x18: 00000000ffffffff
x17: ffff95c6321fdd88 x16: 0000000031427afd x15: 0000000000000100
x14: 0000000000000000 x13: 0000000000077a9a x12: fff000087f805650
x11: fff000087f805630 x10: ffffc1ffe005db08 x9 : 0000000000000000
x8 : 0000000080000000 x7 : ffff80008005bc50 x6 : 000f63580145a000
x5 : ffff95c6322f8000 x4 : 0000000000000000 x3 : 000000000000003f
x2 : 0000000000000040 x1 : fff00000748f9000 x0 : fff00000748f7000
Call trace:
dcache_clean_inval_poc+0x24/0x48 (P)
do_one_initcall+0x60/0x1d4
kernel_init_freeable+0x24c/0x2d4
kernel_init+0x24/0x140
ret_from_fork+0x10/0x20
Code: 9ac32042 d1000443 8a230000 d503201f (d50b7e20)
---[ end trace 0000000000000000 ]---
--
Catalin
next prev parent reply other threads:[~2026-04-08 15:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 14:59 [PATCH v3 00/13] arm64: Unmap linear alias of kernel data/bss Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 01/13] arm64: Move the zero page to rodata Ard Biesheuvel
2026-04-08 13:43 ` Catalin Marinas
2026-04-08 15:09 ` Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 02/13] arm64: mm: Preserve existing table mappings when mapping DRAM Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 03/13] arm64: mm: Preserve non-contiguous descriptors " Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 04/13] arm64: mm: Remove bogus stop condition from map_mem() loop Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 05/13] arm64: mm: Drop redundant pgd_t* argument from map_mem() Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 06/13] arm64: mm: Permit contiguous descriptors to be rewritten Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 07/13] arm64: mm: Use hierarchical XN mapping for the fixmap Ard Biesheuvel
2026-04-08 15:45 ` Catalin Marinas [this message]
2026-04-08 15:48 ` Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 08/13] arm64: kfence: Avoid NOMAP tricks when mapping the early pool Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 09/13] arm64: mm: Permit contiguous attribute for preliminary mappings Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 10/13] arm64: Move fixmap page tables to end of kernel image Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 11/13] arm64: mm: Don't abuse memblock NOMAP to check for overlaps Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 12/13] arm64: mm: Map the kernel data/bss read-only in the linear map Ard Biesheuvel
2026-03-20 14:59 ` [PATCH v3 13/13] arm64: mm: Unmap kernel data/bss entirely from " Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=adZ4LpvJJz-3K20O@arm.com \
--to=catalin.marinas@arm.com \
--cc=anshuman.khandual@arm.com \
--cc=ardb+git@google.com \
--cc=ardb@kernel.org \
--cc=kees@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizprucka@google.com \
--cc=mark.rutland@arm.com \
--cc=ryan.roberts@arm.com \
--cc=sethjenkins@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox