From: Raphael Gault <Raphael.Gault@arm.com>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Julien Thierry <Julien.Thierry@arm.com>,
"peterz@infradead.org" <peterz@infradead.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <Will.Deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC V2 00/16] objtool: Add support for Arm64
Date: Tue, 21 May 2019 12:50:57 +0000 [thread overview]
Message-ID: <26692833-0e5b-cfe0-0ffd-c2c2f0815935@arm.com> (raw)
In-Reply-To: <20190516142917.nuhh6dmfiufxqzls@treble>
Hi Josh,
Thanks for offering your help and sorry for the late answer.
My understanding is that a table of offsets is built by GCC, those
offsets being scaled by 4 before adding them to the base label.
I believe the offsets are stored in the .rodata section. To find the
size of that table, it is needed to find a comparison, which can be
optimized out apprently. In that case the end of the array can be found
by locating labels pointing to data behind it (which is not 100% safe).
On 5/16/19 3:29 PM, Josh Poimboeuf wrote:
> On Thu, May 16, 2019 at 11:36:39AM +0100, Raphael Gault wrote:
>> Noteworthy points:
>> * I still haven't figured out how to detect switch-tables on arm64. I
>> have a better understanding of them but still haven't implemented checks
>> as it doesn't look trivial at all.
>
> Switch tables were tricky to get right on x86. If you share an example
> (or even just a .o file) I can take a look. Hopefully they're somewhat
> similar to x86 switch tables. Otherwise we may want to consider a
> different approach (for example maybe a GCC plugin could help annotate
> them).
>
The case which made me realize the issue is the one of
arch/arm64/kernel/module.o:apply_relocate_add:
```
What seems to happen in the case of module.o is:
334: 90000015 adrp x21, 0 <do_reloc>
which retrieves the location of an offset in the rodata section, and a
bit later we do some extra computation with it in order to compute the
jump destination:
3e0: 78625aa0 ldrh w0, [x21, w2, uxtw #1]
3e4: 10000061 adr x1, 3f0 <apply_relocate_add+0xf8>
3e8: 8b20a820 add x0, x1, w0, sxth #2
3ec: d61f0000 br x0
```
Please keep in mind that the actual offsets might vary.
I'm happy to provide more details about what I have identified if you
want me to.
Thanks,
--
Raphael Gault
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-05-21 12:51 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-16 10:36 [RFC V2 00/16] objtool: Add support for Arm64 Raphael Gault
2019-05-16 10:36 ` [RFC 01/16] objtool: Add abstraction for computation of symbols offsets Raphael Gault
2019-05-16 10:36 ` [RFC 02/16] objtool: orc: Refactor ORC API for other architectures to implement Raphael Gault
2019-05-16 10:36 ` [RFC 03/16] objtool: Move registers and control flow to arch-dependent code Raphael Gault
2019-05-16 10:36 ` [RFC 04/16] objtool: arm64: Add required implementation for supporting the aarch64 architecture in objtool Raphael Gault
2019-05-16 10:36 ` [RFC 05/16] objtool: arm64: Handle hypercalls as nops Raphael Gault
2019-05-16 10:36 ` [RFC 06/16] arm64: alternative: Mark .altinstr_replacement as containing executable instructions Raphael Gault
2019-05-16 10:36 ` [RFC 07/16] objtool: special: Adapt special section handling Raphael Gault
2019-05-16 10:36 ` [RFC 08/16] objtool: arm64: Adapt the stack frame checks for arm architecture Raphael Gault
2019-05-16 10:36 ` [RFC 09/16] arm64: assembler: Add macro to annotate asm function having non standard stack-frame Raphael Gault
2019-05-16 10:36 ` [RFC 10/16] arm64: sleep: Prevent stack frame warnings from objtool Raphael Gault
2019-05-16 10:36 ` [RFC 11/16] objtool: arm64: Enable stack validation for arm64 Raphael Gault
2019-05-16 10:36 ` [RFC 12/16] arm64: kvm: Annotate non-standard stack frame functions Raphael Gault
2019-05-16 10:36 ` [RFC 13/16] arm64: kernel: Add exception on kuser32 to prevent stack analysis Raphael Gault
2019-05-16 10:36 ` [RFC 14/16] arm64: crypto: Add exceptions for crypto object " Raphael Gault
2019-05-16 10:36 ` [RFC 15/16] objtool: Introduce INSN_UNKNOWN type Raphael Gault
2019-05-16 10:36 ` [RFC 16/16] arm64: kernel: Annotate non-standard stack frame functions Raphael Gault
2019-05-16 14:29 ` [RFC V2 00/16] objtool: Add support for Arm64 Josh Poimboeuf
2019-05-21 12:50 ` Raphael Gault [this message]
2019-05-22 23:11 ` Josh Poimboeuf
2019-05-23 7:31 ` Raphael Gault
2019-05-23 7:59 ` Raphael Gault
2019-05-28 22:24 ` Josh Poimboeuf
2019-06-13 15:55 ` Raphael Gault
2019-06-13 16:09 ` Josh Poimboeuf
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=26692833-0e5b-cfe0-0ffd-c2c2f0815935@arm.com \
--to=raphael.gault@arm.com \
--cc=Catalin.Marinas@arm.com \
--cc=Julien.Thierry@arm.com \
--cc=Will.Deacon@arm.com \
--cc=jpoimboe@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.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