Panic when loading modules with CONFIG_ARM64_BTI_KERNEL

D Scott Phillips scott at os.amperecomputing.com
Wed Aug 17 16:42:43 PDT 2022


Hi all,

I'm occasionally seeing panics due to branch target exceptions when
loading kernel modules when bti is enabled. It seems to happen when
__init code calls into non __init code which happens to have been loaded
a long way away, and so a module plt entry has been created.  When the
code for the module was generated, the call from init to non-init was
through a direct branch, so no `bti c` was injected in the callee.

I believe gcc needs to inject bti instructions due to those
cross-section calls regardless of direct/indirect, so I've filed:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671

for the issue, along with a little snippet that makes the same type of
issue happen in user space.

In the meantime, should we mark BTI_KERNEL as broken? or any other ideas
on how to work around code generated without bti instructions like this?
Enable the guard page attribute later? or try to keep init and non-init
allocations close together?

And then finally, here are the exact instructions that are causing me
problems most frequently, from ipmi_si.ko:

> Disassembly of section .init.text:
> 
> 0000000000000000 <init_module>:
>  ... snip ...
>  158:   94000000        bl      0 <init_module>
>                         158: R_AARCH64_CALL26   .text+0x13b4
> 
> Disassembly of section .text:
> 
> 00000000000013b4 <cleanup_ipmi_si.part.0>:
>     13b4:       d503201f        nop
>     13b8:       d503201f        nop
>     13bc:       d503233f        paciasp

Where the plt entry is injected at the call at init_module+0x158, and
then the branch target exception happens at cleanup_ipmi_si.part.0+0x0.

-- 
Scott



More information about the linux-arm-kernel mailing list