Re: [PATCH] arm64/module: Fix livepatch BTI exceptions with Clang 21+

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

Pre-existing issues:
- [High] Direct assignment to read-only memory in `module_emit_plt_entry()` and `module_emit_veneer_for_adrp()` causes a Data Abort kernel panic when resolving livepatch delayed relocations, and misses instruction cache flushing.
--

--- Patch [1]: [PATCH] arm64/module: Fix livepatch BTI exceptions with Clang 21+ ---
commit b15500d2c41dfd08d4a46e3f6cffc977c910f40a
Author: Josh Poimboeuf <[email protected]>

arm64/module: Fix livepatch BTI exceptions with Clang 21+

This commit fixes a BTI exception during livepatch module loading by using
RET instead of BR when branching to static functions that lack a BTI landing
pad. It introduces a check for landing pads and adjusts the branch
instruction emitted by get_plt_entry().

> diff --git a/arch/arm64/kernel/module-plts.c b/arch/arm64/kernel/module-plts.c
> index 7afd370da9f48..4249b477daa8b 100644
> --- a/arch/arm64/kernel/module-plts.c
> +++ b/arch/arm64/kernel/module-plts.c

[ ... ]

> @@ -23,14 +26,45 @@ static struct plt_entry __get_adrp_add_pair(u64 dst, u64 pc,
>  	return (struct plt_entry){ cpu_to_le32(adrp), cpu_to_le32(add) };
>  }
>  
> +static bool plt_target_has_landing_pad(u64 dst)
> +{

[Severity: High]
This is a pre-existing issue, but does direct assignment to the PLT memory
region cause a Data Abort when livepatch resolves delayed relocations?

When a target module is loaded after a livepatch is active,
apply_relocate_add() calls module_emit_plt_entry() on the livepatch module.
Because the livepatch module is already in a live state, its .plt section
has been marked read-only via strict_module_rwx().

Looking at module_emit_plt_entry() in arch/arm64/kernel/module-plts.c:

module_emit_plt_entry() {
    ...
    plt[i] = get_plt_entry(val, &plt[i]);
    ...
}

And similarly in module_emit_veneer_for_adrp():

module_emit_veneer_for_adrp() {
    ...
    plt[i] = __get_adrp_add_pair(val, (u64)&plt[i], rd);
    plt[i].br = cpu_to_le32(br);
    ...
}

Since this direct assignment bypasses __text_poke() or aarch64_insn_copy(),
does it trigger a panic due to writing to read-only memory, and also fail
to flush the instruction cache for the newly emitted PLT entry?

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