From: Peter Zijlstra <peterz@infradead.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Josh Poimboeuf <jpoimboe@redhat.com>,
clang-built-linux <clang-built-linux@googlegroups.com>,
Kees Cook <keescook@google.com>,
LKML <linux-kernel@vger.kernel.org>,
Craig Topper <craig.topper@intel.com>,
Alexander Potapenko <glider@google.com>,
Bill Wendling <morbo@google.com>,
Stephen Hines <srhines@google.com>
Subject: Re: objtool warnings in prerelease clang-9
Date: Wed, 3 Jul 2019 00:07:39 +0200 [thread overview]
Message-ID: <20190702220739.GJ32547@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <CAKwvOdnGL_9cJ+ETNce89+z7CTDctjACS8DFsLu=ev4+vkVkUw@mail.gmail.com>
Hi Nick,
That is good news; and I'll strive to read the email in more detail
in the morning when there is a better chance of me actually
understanding some of it :-)
But his here is something I felt needed clarification:
On Tue, Jul 02, 2019 at 01:53:51PM -0700, Nick Desaulniers wrote:
> Of interest are the disassembled __jump_table entries; in groups of
> three, there is a group for which the second element is duplicated
> with a previous group. This is bad because (as explained by Peter in
> https://lkml.org/lkml/2019/6/27/118) the triples are in the form (code
> location, jump target, pointer to key). Duplicate or repeated jump
> targets are unexpected, and will lead to incorrect control flow after
> patching such code locations.
> Also, the jump target should be 0x7 bytes ahead of the location, IIUC.
Even if you mean 'at least' I'm fairly sure this is not correct. The
instruction at the 'code location' is either a jmp.d32 or a nop5 (both 5
bytes). The target must (obviously) be at an instruction boundary, but
really can be anywhere (it is compiler generated after all).
next prev parent reply other threads:[~2019-07-03 1:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-02 20:53 Nick Desaulniers
2019-07-02 21:58 ` Thomas Gleixner
2019-07-02 22:09 ` Nick Desaulniers
2019-07-02 22:20 ` Thomas Gleixner
2019-07-02 22:33 ` Nick Desaulniers
2019-07-06 15:50 ` Josh Poimboeuf
2019-07-10 23:22 ` Josh Poimboeuf
2019-07-10 23:42 ` Nick Desaulniers
2019-07-11 0:04 ` Josh Poimboeuf
2019-07-02 22:07 ` Peter Zijlstra [this message]
2019-07-03 0:30 ` Nick Desaulniers
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=20190702220739.GJ32547@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=clang-built-linux@googlegroups.com \
--cc=craig.topper@intel.com \
--cc=glider@google.com \
--cc=jpoimboe@redhat.com \
--cc=keescook@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=morbo@google.com \
--cc=ndesaulniers@google.com \
--cc=srhines@google.com \
--cc=tglx@linutronix.de \
/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
Powered by JetHome