linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: D Scott Phillips <scott@os.amperecomputing.com>
To: linux-arm-kernel@lists.infradead.org
Cc: Mark Brown <broonie@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Darren Hart <darren@os.amperecomputing.com>
Subject: Panic when loading modules with CONFIG_ARM64_BTI_KERNEL
Date: Wed, 17 Aug 2022 16:42:43 -0700	[thread overview]
Message-ID: <864jya4eto.fsf@scott-ph-mail.amperecomputing.com> (raw)

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2022-08-17 23:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-17 23:42 D Scott Phillips [this message]
2022-08-18 15:21 ` Panic when loading modules with CONFIG_ARM64_BTI_KERNEL Mark Brown
2022-08-18 16:22   ` D Scott Phillips

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=864jya4eto.fsf@scott-ph-mail.amperecomputing.com \
    --to=scott@os.amperecomputing.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=darren@os.amperecomputing.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --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;
as well as URLs for NNTP newsgroup(s).