From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Nick Desaulniers <ndesaulniers@google.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: Mon, 15 Jul 2019 12:29:34 -0500 [thread overview]
Message-ID: <20190715172934.4uinmu3ba65vcphv@treble> (raw)
In-Reply-To: <CAKwvOdmUX31KcvDpdzOkrO=Jw+FFQ8MuiQkVFFnNeG9n28k5Aw@mail.gmail.com>
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 ?
> Any special configuration?
Arnd shared the config and the .o file here:
https://lkml.kernel.org/r/CAK8P3a2beBPP+KX4zTfSfFPwo+7ksWZLqZzpP9BJ80iPecg3zA@mail.gmail.com
I used Arnd's .o file for testing.
--
Josh
next prev parent reply other threads:[~2019-07-15 17:29 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 [this message]
2019-07-18 23:02 ` Nick Desaulniers
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=20190715172934.4uinmu3ba65vcphv@treble \
--to=jpoimboe@redhat.com \
--cc=arnd@arndb.de \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ndesaulniers@google.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.