Panic when loading modules with CONFIG_ARM64_BTI_KERNEL

[Mark Brown]

On Wed, Aug 17, 2022 at 04:42:43PM -0700, D Scott Phillips wrote:

> In the meantime, should we mark BTI_KERNEL as broken? or any other ideas

The clang versions I have to hand appear fine with your userspace test
program, it emits a BTI C at the start of func with -O1 so I guess
that'd only be for GCC.  Ideally we'd be able to detect particular
configurations that would trigger this but I don't think we can.

> 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?

Keeping the allocations closer so we don't need veneers would mitigate
the issue, though that's not going to be something that we can rely on
so it's awkward - we can *try* to keep them closer together but I'm sure
someone will always be able to craft a case where we get pushed to using
a veneer again.

Not enabling BTI for the module until after init has run would mean that
we'd have to remap the code while things like interrupt handlers might
be running which smells like there'd be problems but I'd need to go and
refresh my memory as to what the actual issues are.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20220818/b09dda76/attachment.sig>