From: Nick Desaulniers <ndesaulniers@google.com>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Arnd Bergmann <arnd@arndb.de>, Jann Horn <jannh@google.com>,
Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [PATCH 20/22] objtool: Fix seg fault on bad switch table entry
Date: Thu, 18 Jul 2019 16:02:46 -0700 [thread overview]
Message-ID: <CAKwvOd=5jJxkRaAC+sEYOd9s3vfWDdQzN-a3YxHh-Qen7FHBpA@mail.gmail.com> (raw)
In-Reply-To: <20190715172934.4uinmu3ba65vcphv@treble>
On Mon, Jul 15, 2019 at 10:29 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> On Mon, Jul 15, 2019 at 10:24:24AM -0700, Nick Desaulniers wrote:
> > On Sun, Jul 14, 2019 at 5:37 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> > >
> > > In one rare case, Clang generated the following code:
> > >
> > > 5ca: 83 e0 21 and $0x21,%eax
> > > 5cd: b9 04 00 00 00 mov $0x4,%ecx
> > > 5d2: ff 24 c5 00 00 00 00 jmpq *0x0(,%rax,8)
> > > 5d5: R_X86_64_32S .rodata+0x38
> > >
> > > which uses the corresponding jump table relocations:
> > >
> > > 000000000038 000200000001 R_X86_64_64 0000000000000000 .text + 834
> > > 000000000040 000200000001 R_X86_64_64 0000000000000000 .text + 5d9
> > > 000000000048 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 000000000050 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 000000000058 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 000000000060 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 000000000068 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 000000000070 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 000000000078 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 000000000080 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 000000000088 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 000000000090 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 000000000098 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 0000000000a0 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 0000000000a8 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 0000000000b0 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 0000000000b8 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 0000000000c0 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 0000000000c8 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 0000000000d0 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 0000000000d8 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 0000000000e0 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 0000000000e8 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 0000000000f0 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 0000000000f8 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 000000000100 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 000000000108 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 000000000110 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 000000000118 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 000000000120 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 000000000128 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 000000000130 000200000001 R_X86_64_64 0000000000000000 .text + b96
> > > 000000000138 000200000001 R_X86_64_64 0000000000000000 .text + 82f
> > > 000000000140 000200000001 R_X86_64_64 0000000000000000 .text + 828
> > >
> > > Since %eax was masked with 0x21, only the first two and the last two
> > > entries are possible.
> > >
> > > Objtool doesn't actually emulate all the code, so it isn't smart enough
> > > to know that all the middle entries aren't reachable. They point to the
> > > NOP padding area after the end of the function, so objtool seg faulted
> > > when it tried to dereference a NULL insn->func.
> > >
> > > After this fix, objtool still gives an "unreachable" error because it
> > > stops reading the jump table when it encounters the bad addresses:
> > >
> > > /home/jpoimboe/objtool-tests/adm1275.o: warning: objtool: adm1275_probe()+0x828: unreachable instruction
> > >
> > > While the above code is technically correct, it's very wasteful of
> > > memory -- it uses 34 jump table entries when only 4 are needed. It's
> > > also not possible for objtool to validate this type of switch table
> > > because the unused entries point outside the function and objtool has no
> > > way of determining if that's intentional. Hopefully the Clang folks can
> > > fix it.
> >
> > So this came from
> > drivers/hwmon/pmbus/adm1275.c ?
$ grep switch drivers/hwmon/pmbus/adm1275.c | wc -l
8
$ grep switch drivers/hwmon/pmbus/adm1275.c
switch (reg) {
switch (reg) {
switch (reg) {
switch (data->id) {
switch (config & ADM1075_IRANGE_MASK) {
switch (config & (ADM1275_VRANGE | ADM1272_IRANGE)) {
switch (config & ADM1293_VIN_SEL_MASK) {
switch (config & ADM1293_IRANGE_MASK) {
Looking specifically at the definition of adm1275_probe, I see:
...
switch (data->id) {
...
switch (config & ADM1075_IRANGE_MASK) {
...
switch (config & (ADM1275_VRANGE | ADM1272_IRANGE)) {
...
switch (config & ADM1293_VIN_SEL_MASK) {
...
switch (config & ADM1293_IRANGE_MASK) {
So I assume that the two level switch statement is somehow related.
Maybe the two level switch is transformed into a one level switch with
duplicated case labels? Let me play around in <strikethrough>my
sandbox</strikethrough>godbolt and see if I can reproduce with that
pattern.
--
Thanks,
~Nick Desaulniers
next prev parent reply other threads:[~2019-07-18 23:03 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-15 0:36 [PATCH 00/22] x86, objtool: several fixes/improvements Josh Poimboeuf
2019-07-15 0:36 ` [PATCH 01/22] x86/paravirt: Fix callee-saved function ELF sizes Josh Poimboeuf
2019-07-15 4:58 ` Juergen Gross
2019-07-15 12:43 ` Josh Poimboeuf
2019-07-15 0:36 ` [PATCH 02/22] x86/kvm: Fix fastop function ELF metadata Josh Poimboeuf
2019-07-15 9:05 ` Paolo Bonzini
2019-07-15 0:36 ` [PATCH 03/22] x86/kvm: Fix frame pointer usage in vmx_vmenter() Josh Poimboeuf
2019-07-15 9:04 ` Paolo Bonzini
2019-07-15 12:37 ` Josh Poimboeuf
2019-07-15 13:03 ` Paolo Bonzini
2019-07-15 13:35 ` Josh Poimboeuf
2019-07-15 18:17 ` Paolo Bonzini
2019-07-15 0:36 ` [PATCH 04/22] x86/kvm: Don't call kvm_spurious_fault() from .fixup Josh Poimboeuf
2019-07-15 9:07 ` Paolo Bonzini
2019-07-15 12:40 ` Josh Poimboeuf
2019-07-15 13:05 ` Paolo Bonzini
2019-07-15 13:25 ` Josh Poimboeuf
2019-07-15 18:16 ` Paolo Bonzini
2019-07-15 0:37 ` [PATCH 05/22] x86/entry: Fix thunk function ELF sizes Josh Poimboeuf
2019-07-15 0:37 ` [PATCH 06/22] x86/head/64: Annotate start_cpu0() as non-callable Josh Poimboeuf
2019-07-15 0:37 ` [PATCH 07/22] x86/uaccess: Remove ELF function annotation from copy_user_handle_tail() Josh Poimboeuf
2019-07-16 18:16 ` Nick Desaulniers
2019-07-16 18:51 ` Peter Zijlstra
2019-07-15 0:37 ` [PATCH 08/22] x86/uaccess: Don't leak AC flag into fentry from mcsafe_handle_tail() Josh Poimboeuf
2019-07-15 0:37 ` [PATCH 09/22] x86/uaccess: Remove redundant CLACs in getuser/putuser error paths Josh Poimboeuf
2019-07-15 0:37 ` [PATCH 10/22] bpf: Disable GCC -fgcse optimization for ___bpf_prog_run() Josh Poimboeuf
2019-07-16 18:15 ` Nick Desaulniers
2019-07-16 23:02 ` Josh Poimboeuf
2019-07-15 0:37 ` [PATCH 11/22] objtool: Add mcsafe_handle_tail() to the uaccess safe list Josh Poimboeuf
2019-07-15 0:37 ` [PATCH 12/22] objtool: Track original function across branches Josh Poimboeuf
2019-07-15 0:37 ` [PATCH 13/22] objtool: Refactor function alias logic Josh Poimboeuf
2019-07-15 0:37 ` [PATCH 14/22] objtool: Warn on zero-length functions Josh Poimboeuf
2019-07-15 0:37 ` [PATCH 15/22] objtool: Change dead_end_function() to return boolean Josh Poimboeuf
2019-07-15 0:37 ` [PATCH 16/22] objtool: Do frame pointer check before dead end check Josh Poimboeuf
2019-07-15 0:37 ` [PATCH 17/22] objtool: Refactor sibling call detection logic Josh Poimboeuf
2019-07-15 0:37 ` [PATCH 18/22] objtool: Refactor jump table code Josh Poimboeuf
2019-07-15 9:38 ` Peter Zijlstra
2019-07-15 0:37 ` [PATCH 19/22] objtool: Support repeated uses of the same C jump table Josh Poimboeuf
2019-07-15 0:37 ` [PATCH 20/22] objtool: Fix seg fault on bad switch table entry Josh Poimboeuf
2019-07-15 17:24 ` Nick Desaulniers
2019-07-15 17:29 ` Josh Poimboeuf
2019-07-18 23:02 ` Nick Desaulniers [this message]
2019-07-15 0:37 ` [PATCH 21/22] objtool: convert insn type to enum Josh Poimboeuf
2019-07-15 0:37 ` [PATCH 22/22] objtool: Support conditional retpolines Josh Poimboeuf
2019-07-15 9:52 ` [PATCH 00/22] x86, objtool: several fixes/improvements Peter Zijlstra
2019-07-15 19:38 ` Josh Poimboeuf
2019-07-15 21:45 ` Nick Desaulniers
2019-07-16 23:17 ` Josh Poimboeuf
2019-07-18 22:26 ` Nick Desaulniers
2019-09-27 20:24 ` 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='CAKwvOd=5jJxkRaAC+sEYOd9s3vfWDdQzN-a3YxHh-Qen7FHBpA@mail.gmail.com' \
--to=ndesaulniers@google.com \
--cc=arnd@arndb.de \
--cc=jannh@google.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@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).