[PATCH 01/12] arm64/bti: Add BTI landing pad to __sdei_asm_handler()

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing BTI landing pads (`bti j`) on indirect branch targets in the KPTI trampoline (`__sdei_asm_exit_trampoline` and `tramp_exit`).
- [High] The KPTI entry trampoline mapping at `TRAMP_VALIAS` lacks the BTI Guarded Page (`PTE_GP`) attribute, disabling hardware CFI checks.
--

--- Patch [1]: [PATCH 01/12] arm64/bti: Add BTI landing pad to __sdei_asm_handler() ---
commit 59fadd16326c687a5994c4bec81d9484edcc08f9
Author: Josh Poimboeuf <jpoimboe at kernel.org>

arm64/bti: Add BTI landing pad to __sdei_asm_handler()

With CONFIG_UNMAP_KERNEL_AT_EL0, __sdei_asm_entry_trampoline() indirect
jumps to __sdei_asm_handler(). Add "bti j" to prevent a Branch Target
exception.

> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index e0db14e9c843a..16c21fcb41976 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -976,6 +976,7 @@ NOKPROBE(__sdei_asm_exit_trampoline)

[Severity: High]
This is a pre-existing issue, but do we also need bti j landing pads on the
indirect branch targets for the exit paths?

For example, __sdei_asm_exit_trampoline() is called via an indirect branch
(br x5):

arch/arm64/kernel/entry.S:__sdei_asm_exit_trampoline() {
    SYM_CODE_START(__sdei_asm_exit_trampoline)
        ldr x4, [x4, #(SDEI_EVENT_INTREGS + S_SDEI_TTBR1)]
        ...
}

Similarly, tramp_exit() in the same file lacks a landing pad despite being
called via an indirect branch (br x29) on the EL0 exit path:

arch/arm64/kernel/entry.S:tramp_exit() {
    SYM_CODE_START_LOCAL(tramp_exit)
        tramp_unmap_kernel x29
        ...
}

Would it be better to add bti j annotations to these functions as well to
prevent Branch Target exceptions?


[Severity: High]
This isn't a bug introduced by this patch, but does the KPTI trampoline mapping
need the BTI Guarded Page (PTE_GP) attribute?

Looking at map_entry_trampoline() in arch/arm64/mm/mmu.c, it uses
kernel_exec_prot() to map the trampoline text:

arch/arm64/mm/mmu.c:map_entry_trampoline() {
    pgprot_t prot = kernel_exec_prot();
    ...
    early_create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS,
                             entry_tramp_text_size(), prot,
                             pgd_pgtable_alloc_init_mm, NO_BLOCK_MAPPINGS);
}

The prot variable is derived from PAGE_KERNEL_ROX, which does not appear to
contain the PTE_GP bit. Does this inadvertently disable hardware BTI enforcement
for the trampoline pages? If so, could this architectural gap be masking the
missing bti j annotations on the trampoline exit paths mentioned above?

>   * want them.
>   */
>  SYM_CODE_START(__sdei_asm_handler)
> +	bti	j
>  	stp     x2, x3, [x1, #SDEI_EVENT_INTREGS + S_PC]
>  	stp     x4, x5, [x1, #SDEI_EVENT_INTREGS + 16 * 2]
>  	stp     x6, x7, [x1, #SDEI_EVENT_INTREGS + 16 * 3]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1786768375.git.jpoimboe@kernel.org?part=1