17 Dec, 2020
1 commit
-
Add the --mcount option for generating __mcount_loc sections
needed for dynamic ftrace. Using this pass requires the kernel to
be compiled with -mfentry and CC_USING_NOP_MCOUNT to be defined
in Makefile.Bug: 145210207
Change-Id: I34eeeb00c184bf265391549094fc15525536886b
Link: https://lore.kernel.org/lkml/20200625200235.GQ4781@hirez.programming.kicks-ass.net/
Signed-off-by: Peter Zijlstra
[Sami: rebased, dropped config changes, fixed to actually use --mcount,
and wrote a commit message.]
Signed-off-by: Sami Tolvanen
Reviewed-by: Kees Cook
10 Sep, 2020
2 commits
-
The way to identify jump tables and retrieve all the data necessary to
handle the different execution branches is not the same on all
architectures. In order to be able to add other architecture support,
define an arch-dependent function to process jump-tables.Reviewed-by: Miroslav Benes
Signed-off-by: Raphael Gault
[J.T.: Move arm64 bits out of this patch,
Have only one function to find the start of the jump table,
for now assume that the jump table format will be the same as
x86]
Signed-off-by: Julien Thierry
Signed-off-by: Josh Poimboeuf -
As pointed out by the comment in handle_group_alt(), support of
relocation for instructions in an alternative group depends on whether
arch specific kernel code handles it.So, let objtool arch specific code decide whether a relocation for
the alternative section should be accepted.Reviewed-by: Miroslav Benes
Signed-off-by: Julien Thierry
Signed-off-by: Josh Poimboeuf
02 Sep, 2020
1 commit
-
Implementation of ORC requires some definitions that are currently
provided by the target architecture headers. Do not depend on these
definitions when the orc subcommand is not implemented.This avoid requiring arches with no orc implementation to provide dummy
orc definitions.Signed-off-by: Julien Thierry
Reviewed-by: Miroslav Benes
Signed-off-by: Josh Poimboeuf
01 Sep, 2020
1 commit
-
Add the inline static call implementation for x86-64. The generated code
is identical to the out-of-line case, except we move the trampoline into
it's own section.Objtool uses the trampoline naming convention to detect all the call
sites. It then annotates those call sites in the .static_call_sites
section.During boot (and module init), the call sites are patched to call
directly into the destination function. The temporary trampoline is
then no longer used.[peterz: merged trampolines, put trampoline in section]
Signed-off-by: Josh Poimboeuf
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Ingo Molnar
Cc: Linus Torvalds
Link: https://lore.kernel.org/r/20200818135804.864271425@infradead.org
01 Jun, 2020
1 commit
-
Before supporting additional relocation types rename the relevant
types and functions from "rela" to "reloc". This work be done with
the following regex:sed -e 's/struct rela/struct reloc/g' \
-e 's/\([_\*]\)rela\(s\{0,1\}\)/\1reloc\2/g' \
-e 's/tmprela\(s\{0,1\}\)/tmpreloc\1/g' \
-e 's/relasec/relocsec/g' \
-e 's/rela_list/reloc_list/g' \
-e 's/rela_hash/reloc_hash/g' \
-e 's/add_rela/add_reloc/g' \
-e 's/rela->/reloc->/g' \
-e '/rela[,\.]/{ s/\([^\.>]\)rela\([\.,]\)/\1reloc\2/g ; }' \
-e 's/rela =/reloc =/g' \
-e 's/relas =/relocs =/g' \
-e 's/relas\[/relocs[/g' \
-e 's/relaname =/relocname =/g' \
-e 's/= rela\;/= reloc\;/g' \
-e 's/= relas\;/= relocs\;/g' \
-e 's/= relaname\;/= relocname\;/g' \
-e 's/, rela)/, reloc)/g' \
-e 's/\([ @]\)rela\([ "]\)/\1reloc\2/g' \
-e 's/ rela$/ reloc/g' \
-e 's/, relaname/, relocname/g' \
-e 's/sec->rela/sec->reloc/g' \
-e 's/(\(!\{0,1\}\)rela/(\1reloc/g' \
-i \
arch.h \
arch/x86/decode.c \
check.c \
check.h \
elf.c \
elf.h \
orc_gen.c \
special.cNotable exceptions which complicate the regex include gelf_*
library calls and standard/expected section names which still use
"rela" because they encode the type of relocation expected. Also, keep
"rela" in the struct because it encodes a specific type of relocation
we currently expect.It will eventually turn into a member of an anonymous union when a
susequent patch adds implicit addend, or "rel", relocation support.Signed-off-by: Matt Helsley
Signed-off-by: Josh Poimboeuf
20 May, 2020
2 commits
-
Objtool currently only compiles for x86 architectures. This is
fine as it presently does not support tooling for other
architectures. However, we would like to be able to convert other
kernel tools to run as objtool sub commands because they too
process ELF object files. This will allow us to convert tools
such as recordmcount to use objtool's ELF code.Since much of recordmcount's ELF code is copy-paste code to/from
a variety of other kernel tools (look at modpost for example) this
means that if we can convert recordmcount we can convert more.We define weak definitions for subcommand entry functions and other weak
definitions for shared functions critical to building existing
subcommands. These return 127 when the command is missing which signify
tools that do not exist on all architectures. In this case the "check"
and "orc" tools do not exist on all architectures so we only add them
for x86. Future changes adding support for "check", to arm64 for
example, can then modify the SUBCMD_CHECK variable when building for
arm64.Objtool is not currently wired in to KConfig to be built for other
architectures because it's not needed for those architectures and
there are no commands it supports other than those for x86. As more
command support is enabled on various architectures the necessary
KConfig changes can be made (e.g. adding "STACK_VALIDATION") to
trigger building objtool.[ jpoimboe: remove aliases, add __weak macro, add error messages ]
Cc: Julien Thierry
Signed-off-by: Matt Helsley
Signed-off-by: Josh Poimboeuf -
The objtool_file structure describes the files objtool works on,
is used by the check subcommand, and the check.h header is included
by the orc subcommands so it's presently used by all subcommands.Since the structure will be useful in all subcommands besides check,
and some subcommands may not want to include check.h to get the
definition, split the structure out into a new header meant for use
by all objtool subcommands.Signed-off-by: Matt Helsley
Reviewed-by: Julien Thierry
Signed-off-by: Josh Poimboeuf
01 May, 2020
1 commit
-
Assign a unique identifier to every alternative instruction group in
order to be able to tell which instructions belong to what
alternative.[peterz: extracted from a larger patch]
Signed-off-by: Alexandre Chartre
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Miroslav Benes
22 Apr, 2020
5 commits
-
Validate that any call out of .noinstr.text is in between
instr_begin() and instr_end() annotations.This annotation is useful to ensure correct behaviour wrt tracing
sensitive code like entry/exit and idle code. When we run code in a
sensitive context we want a guarantee no unknown code is ran.Since this validation relies on knowing the section of call
destination symbols, we must run it on vmlinux.o instead of on
individual object files.Add two options:
-d/--duplicate "duplicate validation for vmlinux"
-l/--vmlinux "vmlinux.o validation"Where the latter auto-detects when objname ends with "vmlinux.o" and
the former will force all validations, also those already done on
!vmlinux object files.Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Miroslav Benes
Reviewed-by: Alexandre Chartre
Acked-by: Josh Poimboeuf
Link: https://lkml.kernel.org/r/20200416115119.106268040@infradead.org
Signed-off-by: Ingo Molnar -
Objtool keeps per instruction CFI state in struct insn_state and will
save/restore this where required. However, insn_state has grown some
!CFI state, and this must not be saved/restored (that would
loose/destroy state).Fix this by moving the CFI specific parts of insn_state into struct
cfi_state.Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Miroslav Benes
Reviewed-by: Alexandre Chartre
Acked-by: Josh Poimboeuf
Link: https://lkml.kernel.org/r/20200416115119.045821071@infradead.org
Signed-off-by: Ingo Molnar -
The SAVE/RESTORE hints are now unused; remove them.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Miroslav Benes
Reviewed-by: Alexandre Chartre
Acked-by: Josh Poimboeuf
Link: https://lkml.kernel.org/r/20200416115118.926738768@infradead.org
Signed-off-by: Ingo Molnar -
Normally objtool ensures a function keeps the stack layout invariant.
But there is a useful exception, it is possible to stuff the return
stack in order to 'inject' a 'call':push $fun
retIn this case the invariant mentioned above is violated.
Add an objtool HINT to annotate this and allow a function exit with a
modified stack frame.Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Miroslav Benes
Reviewed-by: Alexandre Chartre
Acked-by: Josh Poimboeuf
Link: https://lkml.kernel.org/r/20200416115118.690601403@infradead.org
Signed-off-by: Ingo Molnar -
Instruction sets can include more or less complex operations which might
not fit the currently defined set of stack_ops.Combining more than one stack_op provides more flexibility to describe
the behaviour of an instruction. This also reduces the need to define
new stack_ops specific to a single instruction set.Allow instruction decoders to generate multiple stack_op per
instruction.Signed-off-by: Julien Thierry
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Miroslav Benes
Reviewed-by: Alexandre Chartre
Acked-by: Josh Poimboeuf
Link: https://lkml.kernel.org/r/20200327152847.15294-11-jthierry@redhat.com
Signed-off-by: Ingo Molnar
26 Mar, 2020
1 commit
-
Perf shows we're spending a lot of time in find_insn() and the
statistics show we have around 3.2 million instruction. Increase the
hash table size to reduce the bucket load from around 50 to 3.This shaves about 2s off of objtool on vmlinux.o runtime, down to 16s.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Miroslav Benes
Acked-by: Josh Poimboeuf
Link: https://lkml.kernel.org/r/20200324160924.617882545@infradead.org
25 Jul, 2019
1 commit
-
A clang build reported an (obvious) double CLAC while a GCC build did not;
it turns out that objtool only re-visits instructions if the first visit
was with AC=0. If OTOH the first visit was with AC=1, it completely ignores
any subsequent visit, even when it has AC=0.Fix this by using a visited mask instead of a boolean, and (explicitly)
mark the AC state.$ ./objtool check -b --no-fp --retpoline --uaccess drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: .altinstr_replacement+0x22: redundant UACCESS disable
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: eb_copy_relocations.isra.34()+0xea: (alt)
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: .altinstr_replacement+0xffffffffffffffff: (branch)
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: eb_copy_relocations.isra.34()+0xd9: (alt)
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: eb_copy_relocations.isra.34()+0xb2: (branch)
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: eb_copy_relocations.isra.34()+0x39: (branch)
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: eb_copy_relocations.isra.34()+0x0:
Reported-by: Thomas Gleixner
Reported-by: Sedat Dilek
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Josh Poimboeuf
Signed-off-by: Thomas Gleixner
Tested-by: Nathan Chancellor
Tested-by: Nick Desaulniers
Tested-by: Sedat Dilek
Link: https://github.com/ClangBuiltLinux/linux/issues/617
Link: https://lkml.kernel.org/r/5359166aad2d53f3145cd442d83d0e5115e0cd17.1564007838.git.jpoimboe@redhat.com
19 Jul, 2019
2 commits
-
This makes it easier to add new instruction types. Also it's hopefully
more robust since the compiler should warn about out-of-range enums.Signed-off-by: Josh Poimboeuf
Signed-off-by: Thomas Gleixner
Tested-by: Nick Desaulniers
Acked-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/0740e96af0d40e54cfd6a07bf09db0fbd10793cd.1563413318.git.jpoimboe@redhat.com -
This fixes objtool for both a GCC issue and a Clang issue:
1) GCC issue:
kernel/bpf/core.o: warning: objtool: ___bpf_prog_run()+0x8d5: sibling call from callable instruction with modified stack frame
With CONFIG_RETPOLINE=n, GCC is doing the following optimization in
___bpf_prog_run().Before:
select_insn:
jmp *jumptable(,%rax,8)
...
ALU64_ADD_X:
...
jmp select_insn
ALU_ADD_X:
...
jmp select_insnAfter:
select_insn:
jmp *jumptable(, %rax, 8)
...
ALU64_ADD_X:
...
jmp *jumptable(, %rax, 8)
ALU_ADD_X:
...
jmp *jumptable(, %rax, 8)This confuses objtool. It has never seen multiple indirect jump
sites which use the same jump table.For GCC switch tables, the only way of detecting the size of a table
is by continuing to scan for more tables. The size of the previous
table can only be determined after another switch table is found, or
when the scan reaches the end of the function.That logic was reused for C jump tables, and was based on the
assumption that each jump table only has a single jump site. The
above optimization breaks that assumption.2) Clang issue:
drivers/usb/misc/sisusbvga/sisusb.o: warning: objtool: sisusb_write_mem_bulk()+0x588: can't find switch jump table
With clang 9, code can be generated where a function contains two
indirect jump instructions which use the same switch table.The fix is the same for both issues: split the jump table parsing into
two passes.In the first pass, locate the heads of all switch tables for the
function and mark their locations.In the second pass, parse the switch tables and add them.
Fixes: e55a73251da3 ("bpf: Fix ORC unwinding in non-JIT BPF code")
Reported-by: Randy Dunlap
Reported-by: Arnd Bergmann
Signed-off-by: Jann Horn
Signed-off-by: Josh Poimboeuf
Signed-off-by: Thomas Gleixner
Tested-by: Nick Desaulniers
Acked-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/e995befaada9d4d8b2cf788ff3f566ba900d2b4d.1563413318.git.jpoimboe@redhat.comCo-developed-by: Josh Poimboeuf
21 May, 2019
1 commit
-
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version this program is distributed in the
hope that it will be useful but without any warranty without even
the implied warranty of merchantability or fitness for a particular
purpose see the gnu general public license for more details you
should have received a copy of the gnu general public license along
with this program if not see http www gnu org licensesthis program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version this program is distributed in the
hope that it will be useful but without any warranty without even
the implied warranty of merchantability or fitness for a particular
purpose see the gnu general public license for more details [based]
[from] [clk] [highbank] [c] you should have received a copy of the
gnu general public license along with this program if not see http
www gnu org licensesextracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 355 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Kate Stewart
Reviewed-by: Jilayne Lovejoy
Reviewed-by: Steve Winslow
Reviewed-by: Allison Randal
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190519154041.837383322@linutronix.de
Signed-off-by: Greg Kroah-Hartman
03 Apr, 2019
3 commits
-
Having DF escape is BAD(tm).
Linus; you suggested this one, but since DF really is only used from
ASM and the failure case is fairly obvious, do we really need this?OTOH the patch is fairly small and simple, so let's just do this
to demonstrate objtool's superior awesomeness.Suggested-by: Linus Torvalds
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Josh Poimboeuf
Cc: Borislav Petkov
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Signed-off-by: Ingo Molnar -
It is important that UACCESS regions are as small as possible;
furthermore the UACCESS state is not scheduled, so doing anything that
might directly call into the scheduler will cause random code to be
ran with UACCESS enabled.Teach objtool too track UACCESS state and warn about any CALL made
while UACCESS is enabled. This very much includes the __fentry__()
and __preempt_schedule() calls.Note that exceptions _do_ save/restore the UACCESS state, and therefore
they can drive preemption. This also means that all exception handlers
must have an otherwise redundant UACCESS disable instruction;
therefore ignore this warning for !STT_FUNC code (exception handlers
are not normal functions).Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Josh Poimboeuf
Cc: Borislav Petkov
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Signed-off-by: Ingo Molnar -
The whole add_ignores() thing was wildly weird; rewrite it according
to 'modern' ways.Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Josh Poimboeuf
Cc: Borislav Petkov
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Signed-off-by: Ingo Molnar
08 Sep, 2018
1 commit
-
Add support for processing switch jump tables in objects with multiple
.rodata sections, such as those created by '-ffunction-sections' and
'-fdata-sections'. Currently, objtool always looks in .rodata for jump
table information, which results in many "sibling call from callable
instruction with modified stack frame" warnings with objects compiled
using those flags.The fix is comprised of three parts:
1. Flagging all .rodata sections when importing ELF information for
easier checking later.2. Keeping a reference to the section each relocation is from in order
to get the list_head for the other relocations in that section.3. Finding jump tables by following relocations to .rodata sections,
rather than always referencing a single global .rodata section.The patch has been tested without data sections enabled and no
differences in the resulting orc unwind information were seen.Note that as objtool adds terminators to end of each .text section the
unwind information generated between a function+data sections build and
a normal build aren't directly comparable. Manual inspection suggests
that objtool is now generating the correct information, or at least
making more of an effort to do so than it did previously.Signed-off-by: Allan Xavier
Signed-off-by: Josh Poimboeuf
Signed-off-by: Thomas Gleixner
Link: https://lkml.kernel.org/r/099bdc375195c490dda04db777ee0b95d566ded1.1536325914.git.jpoimboe@redhat.com
21 Jun, 2018
1 commit
-
The existing UNWIND_HINT_EMPTY annotations happen to be good indicators
of where entry code calls into C code for the first time. So also use
them to mark the end of the stack for the ORC unwinder.Use that information to set unwind->error if the ORC unwinder doesn't
unwind all the way to the end. This will be needed for enabling
HAVE_RELIABLE_STACKTRACE for the ORC unwinder so we can use it with the
livepatch consistency model.Thanks to Jiri Slaby for teaching the ORCs about the unwind hints.
Signed-off-by: Josh Poimboeuf
Signed-off-by: Jiri Slaby
Acked-by: Josh Poimboeuf
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link: https://lkml.kernel.org/lkml/20180518064713.26440-5-jslaby@suse.cz
Signed-off-by: Ingo Molnar
21 Feb, 2018
2 commits
-
David requested a objtool validation pass for CONFIG_RETPOLINE=y enabled
builds, where it validates no unannotated indirect jumps or calls are
left.Add an additional .discard.retpoline_safe section to allow annotating
the few indirect sites that are required and safe.Requested-by: David Woodhouse
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: David Woodhouse
Acked-by: Thomas Gleixner
Acked-by: Josh Poimboeuf
Cc: Andy Lutomirski
Cc: Arjan van de Ven
Cc: Borislav Petkov
Cc: Dan Williams
Cc: Dave Hansen
Cc: Greg Kroah-Hartman
Cc: Linus Torvalds
Cc: Peter Zijlstra
Signed-off-by: Ingo Molnar -
Use the existing global variables instead of passing them around and
creating duplicate global variables.Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Thomas Gleixner
Acked-by: Josh Poimboeuf
Cc: Andy Lutomirski
Cc: Arjan van de Ven
Cc: Borislav Petkov
Cc: Dan Williams
Cc: Dave Hansen
Cc: David Woodhouse
Cc: Greg Kroah-Hartman
Cc: Linus Torvalds
Cc: Peter Zijlstra
Signed-off-by: Ingo Molnar
09 Feb, 2018
1 commit
-
Linus reported that GCC-7.3 generated a switch-table construct that
confused objtool. It turns out that, in particular due to KASAN, it is
possible to have unrelated .rodata usage in between the .rodata setup
for the switch-table and the following indirect jump.The simple linear reverse search from the indirect jump would hit upon
the KASAN .rodata usage first and fail to find a switch_table,
resulting in a spurious 'sibling call with modified stack frame'
warning.Fix this by creating a 'jump-stack' which we can 'unwind' during
reversal, thereby skipping over much of the in-between code.This is not fool proof by any means, but is sufficient to make the
known cases work. Future work would be to construct more comprehensive
flow analysis code.Reported-and-tested-by: Linus Torvalds
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Josh Poimboeuf
Cc: Borislav Petkov
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/20180208130232.GF25235@hirez.programming.kicks-ass.net
Signed-off-by: Ingo Molnar
12 Jan, 2018
1 commit
-
Getting objtool to understand retpolines is going to be a bit of a
challenge. For now, take advantage of the fact that retpolines are
patched in with alternatives. Just read the original (sane)
non-alternative instruction, and ignore the patched-in retpoline.This allows objtool to understand the control flow *around* the
retpoline, even if it can't yet follow what's inside. This means the
ORC unwinder will fail to unwind from inside a retpoline, but will work
fine otherwise.Signed-off-by: Josh Poimboeuf
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
Cc: gnomes@lxorguk.ukuu.org.uk
Cc: Rik van Riel
Cc: Andi Kleen
Cc: thomas.lendacky@amd.com
Cc: Peter Zijlstra
Cc: Linus Torvalds
Cc: Jiri Kosina
Cc: Andy Lutomirski
Cc: Dave Hansen
Cc: Kees Cook
Cc: Tim Chen
Cc: Greg Kroah-Hartman
Cc: Paul Turner
Link: https://lkml.kernel.org/r/1515707194-20531-3-git-send-email-dwmw@amazon.co.uk
30 Aug, 2017
1 commit
-
Arnd Bergmann reported the following warning with GCC 7.1.1:
fs/fs_pin.o: warning: objtool: pin_kill()+0x139: stack state mismatch: cfa1=7+88 cfa2=7+96
And the kbuild robot reported the following warnings with GCC 5.4.1:
fs/fs_pin.o: warning: objtool: pin_kill()+0x182: return with modified stack frame
fs/quota/dquot.o: warning: objtool: dquot_alloc_inode()+0x140: stack state mismatch: cfa1=7+120 cfa2=7+128
fs/quota/dquot.o: warning: objtool: dquot_free_inode()+0x11a: stack state mismatch: cfa1=7+112 cfa2=7+120Those warnings are caused by an unusual GCC non-optimization where it
uses an intermediate register to adjust the stack pointer. It does:lea 0x8(%rsp), %rcx
...
mov %rcx, %rspInstead of the obvious:
add $0x8, %rsp
It makes no sense to use an intermediate register, so I opened a GCC bug
to track it:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81813
But it's not exactly a high-priority bug and it looks like we'll be
stuck with this issue for a while. So for now we have to track register
values when they're loaded with stack pointer offsets.This is kind of a big workaround for a tiny problem, but c'est la vie.
I hope to eventually create a GCC plugin to implement a big chunk of
objtool's functionality. Hopefully at that point we'll be able to
remove of a lot of these GCC-isms from the objtool code.Reported-by: Arnd Bergmann
Reported-by: kbuild test robot
Signed-off-by: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/6a41a96884c725e7f05413bb7df40cfe824b2444.1504028945.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar
11 Aug, 2017
1 commit
-
When GCC realigns a function's stack, it sometimes uses %r13 as the DRAP
register, like:push %r13
lea 0x10(%rsp), %r13
and $0xfffffffffffffff0, %rsp
pushq -0x8(%r13)
push %rbp
mov %rsp, %rbp
push %r13
...
mov -0x8(%rbp),%r13
leaveq
lea -0x10(%r13), %rsp
pop %r13
retqSince %r13 was pushed onto the stack twice, its two stack locations need
to be stored separately. The first push of %r13 is its original value,
and the second push of %r13 is the caller's stack frame address.Since %r13 is a callee-saved register, we need to track the stack
location of its original value separately from the DRAP register.This fixes the following false positive warning:
lib/ubsan.o: warning: objtool: val_to_string.constprop.7()+0x97: leave instruction with modified stack frame
Reported-by: Arnd Bergmann
Signed-off-by: Josh Poimboeuf
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Fixes: baa41469a7b9 ("objtool: Implement stack validation 2.0")
Link: http://lkml.kernel.org/r/3da23a6d4c5b3c1e21fc2ccc21a73941b97ff20a.1502401017.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar
25 Jul, 2017
1 commit
-
Objtool tries to silence 'unreachable instruction' warnings when it
detects gcov is enabled, because gcov produces a lot of unreachable
instructions and they don't really matter.However, the 0-day bot is still reporting some unreachable instruction
warnings with CONFIG_GCOV_KERNEL=y on GCC 4.6.4.As it turns out, objtool's gcov detection doesn't work with older
versions of GCC because they don't create a bunch of symbols with the
'gcov.' prefix like newer versions of GCC do.Move the gcov check out of objtool and instead just create a new
'--no-unreachable' flag which can be passed in by the kernel Makefile
when CONFIG_GCOV_KERNEL is defined.Also rename the 'nofp' variable to 'no_fp' for consistency with the new
'no_unreachable' variable.Reported-by: kbuild test robot
Signed-off-by: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Fixes: 9cfffb116887 ("objtool: Skip all "unreachable instruction" warnings for gcov kernels")
Link: http://lkml.kernel.org/r/c243dc78eb2ffdabb6e927844dea39b6033cd395.1500939244.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar
18 Jul, 2017
2 commits
-
Some asm (and inline asm) code does special things to the stack which
objtool can't understand. (Nor can GCC or GNU assembler, for that
matter.) In such cases we need a facility for the code to provide
annotations, so the unwinder can unwind through it.This provides such a facility, in the form of unwind hints. They're
similar to the GNU assembler .cfi* directives, but they give more
information, and are needed in far fewer places, because objtool can
fill in the blanks by following branches and adjusting the stack pointer
for pushes and pops.Signed-off-by: Josh Poimboeuf
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Jiri Slaby
Cc: Linus Torvalds
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: live-patching@vger.kernel.org
Link: http://lkml.kernel.org/r/0f5f3c9104fca559ff4088bece1d14ae3bca52d5.1499786555.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar -
Now that objtool knows the states of all registers on the stack for each
instruction, it's straightforward to generate debuginfo for an unwinder
to use.Instead of generating DWARF, generate a new format called ORC, which is
more suitable for an in-kernel unwinder. See
Documentation/x86/orc-unwinder.txt for a more detailed description of
this new debuginfo format and why it's preferable to DWARF.Signed-off-by: Josh Poimboeuf
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Jiri Slaby
Cc: Linus Torvalds
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: live-patching@vger.kernel.org
Link: http://lkml.kernel.org/r/c9b9f01ba6c5ed2bdc9bb0957b78167fdbf9632e.1499786555.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar
30 Jun, 2017
2 commits
-
This is a major rewrite of objtool. Instead of only tracking frame
pointer changes, it now tracks all stack-related operations, including
all register saves/restores.In addition to making stack validation more robust, this also paves the
way for undwarf generation.Signed-off-by: Josh Poimboeuf
Cc: Andy Lutomirski
Cc: Jiri Slaby
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: live-patching@vger.kernel.org
Link: http://lkml.kernel.org/r/678bd94c0566c6129bcc376cddb259c4c5633004.1498659915.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar -
In preparation for the new 'objtool undwarf generate' command, which
will rely on 'objtool check', move the checking code from
builtin-check.c to check.c where it can be used by other commands.Signed-off-by: Josh Poimboeuf
Reviewed-by: Jiri Slaby
Cc: Andy Lutomirski
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: live-patching@vger.kernel.org
Link: http://lkml.kernel.org/r/294c5c695fd73c1a5000bbe5960a7c9bec4ee6b4.1498659915.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar