From: Peter Zijlstra <peterz@infradead.org>
To: Raphael Gault <Raphael.Gault@arm.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <Will.Deacon@arm.com>,
Julien Thierry <Julien.Thierry@arm.com>
Subject: Re: [RFC 3/6] objtool: arm64: Adapt the stack frame checks and the section analysis for the arm architecture
Date: Thu, 25 Apr 2019 10:33:20 +0200 [thread overview]
Message-ID: <20190425083320.GK4038@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <c90f402e-6494-73bc-1df8-516c3113019a@arm.com>
On Thu, Apr 25, 2019 at 08:12:24AM +0000, Raphael Gault wrote:
> The motivation behind this is that the `br <Xn>` instruction is a
> dynamic jump (jump to the address contained in the provided register).
> This instruction is used for sibling calls but can also be used for
> switch table. I use this to differentiate these two cases from one another:
>
> Generally the `adr/adrp` instruction is used prior to `br` in order to
> load the address into the register. What I do here is go back throught
> the instructions and try to identify if the address loaded.
Yikes, be very careful with simply going back on the instruction stream.
The problem case would be something like:
adr ...
b 1f
...
b ...
1: br ...
In that case, simply going backwards from 1 will not yield the desired
result.
At some point I did a pass storing all the fwd jumps in their
destination and used that to 'rewind' the instruction stream, but that
wasn't very pretty either.
The best way might be to, while doing validate_branch() keep a state
table of all most recent ADR(P) instructions and when encountering BR
check that state to see what it really is.
We currently don't do dynamic insn->type, but it shouldn't be too hard
(famous last words of course).
next prev parent reply other threads:[~2019-04-25 8:33 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-09 13:52 [PATCH 0/6] objtool: Add support for Arm64 Raphael Gault
2019-04-09 13:52 ` [RFC 1/6] objtool: Refactor code to make it more suitable for multiple architecture support Raphael Gault
2019-04-23 20:13 ` Josh Poimboeuf
2019-04-24 16:11 ` Raphael Gault
2019-04-24 16:17 ` Josh Poimboeuf
2019-04-09 13:52 ` [RFC 2/6] objtool: arm64: Add required implementation for supporting the aarch64 architecture in objtool Raphael Gault
2019-04-09 16:20 ` Peter Zijlstra
2019-04-23 20:18 ` Josh Poimboeuf
2019-04-24 16:16 ` Raphael Gault
2019-04-24 16:23 ` Josh Poimboeuf
2019-04-09 13:52 ` [RFC 3/6] objtool: arm64: Adapt the stack frame checks and the section analysis for the arm architecture Raphael Gault
2019-04-09 16:12 ` Peter Zijlstra
2019-04-09 16:24 ` Mark Rutland
2019-04-09 16:27 ` Julien Thierry
2019-04-09 16:33 ` Raphaël Gault
2019-04-23 20:36 ` Josh Poimboeuf
2019-04-24 16:32 ` Raphael Gault
2019-04-24 16:56 ` Josh Poimboeuf
2019-04-25 8:12 ` Raphael Gault
2019-04-25 8:33 ` Peter Zijlstra [this message]
2019-04-25 16:25 ` Josh Poimboeuf
2019-04-30 12:20 ` Raphael Gault
2019-05-01 15:09 ` Raphael Gault
2019-04-24 10:36 ` Julien Thierry
2019-04-09 13:52 ` [RFC 4/6] arm64: assembler: Add macro to annotate asm function having non standard stack-frame Raphael Gault
2019-04-24 10:44 ` Julien Thierry
2019-04-09 13:52 ` [RFC 5/6] arm64: sleep: Add stack frame setup for __cpu_supsend_enter Raphael Gault
2019-04-23 20:37 ` Josh Poimboeuf
2019-04-09 13:52 ` [RFC 6/6] objtool: arm64: Enable stack validation for arm64 Raphael Gault
2019-04-09 14:57 ` [PATCH 0/6] objtool: Add support for Arm64 Josh Poimboeuf
2019-04-09 17:43 ` Ard Biesheuvel
2019-04-10 3:37 ` Josh Poimboeuf
2019-04-10 7:20 ` Julien Thierry
2019-04-23 21:09 ` Josh Poimboeuf
2019-04-24 16:08 ` Raphael Gault
2019-04-24 16:14 ` 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=20190425083320.GK4038@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=Catalin.Marinas@arm.com \
--cc=Julien.Thierry@arm.com \
--cc=Raphael.Gault@arm.com \
--cc=Will.Deacon@arm.com \
--cc=jpoimboe@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.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).