15 Jan, 2021
2 commits
-
With -ffunction-sections, Clang can generate a jump beyond the end of a
section when the section ends in an unreachable instruction. If the
offset matches the section length, use the last instruction as the jump
destination.Bug: 145210207
Change-Id: I422b805fe0e857915f0726404d14f62c01629849
Signed-off-by: Sami Tolvanen -
Skip checking for the compiler-generated jump table symbols when Clang's
Control-Flow Integrity (CFI) is enabled.Bug: 145210207
Change-Id: Icd1fad50214016348289ac5980b062708ab9ecd0
Signed-off-by: Sami Tolvanen
17 Dec, 2020
4 commits
-
This change adds a --noinstr flag to objtool to allow us to specify
that we're processing vmlinux.o without also enabling noinstr
validation. This is needed to avoid false positives with LTO when we
run objtool on vmlinux.o without CONFIG_DEBUG_ENTRY.Bug: 145210207
Change-Id: I479c72d2733844d2059253035391a0c6e8ad7771
Link: https://lore.kernel.org/lkml/20201013003203.4168817-11-samitolvanen@google.com/
Signed-off-by: Sami Tolvanen -
With LTO, we run objtool on vmlinux.o, but don't want noinstr
validation. This change requires --vmlinux to be passed to objtool
explicitly.Bug: 145210207
Change-Id: Ibfd814126df6b3d1a52f5461f2e5aac1377b02c9
Link: https://lore.kernel.org/lkml/20201013003203.4168817-4-samitolvanen@google.com/
Suggested-by: Peter Zijlstra
Signed-off-by: Sami Tolvanen
Reviewed-by: Kees Cook -
When objtool generates relocations for the __mcount_loc section, it
tries to reference __fentry__ calls by their section symbol offset.
However, this fails with Clang's integrated assembler as it may not
generate section symbols for every section. This patch looks up a
function symbol instead if the section symbol is missing, similarly
to commit e81e07244325 ("objtool: Support Clang non-section symbols
in ORC generation").Bug: 145210207
Change-Id: I1069c45a81a3b60eb8f8333581c379701145982f
Signed-off-by: Sami Tolvanen -
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
15 Oct, 2020
1 commit
-
Pull objtool updates from Ingo Molnar:
"Most of the changes are cleanups and reorganization to make the
objtool code more arch-agnostic. This is in preparation for non-x86
support.Other changes:
- KASAN fixes
- Handle unreachable trap after call to noreturn functions better
- Ignore unreachable fake jumps
- Misc smaller fixes & cleanups"
* tag 'objtool-core-2020-10-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (21 commits)
perf build: Allow nested externs to enable BUILD_BUG() usage
objtool: Allow nested externs to enable BUILD_BUG()
objtool: Permit __kasan_check_{read,write} under UACCESS
objtool: Ignore unreachable trap after call to noreturn functions
objtool: Handle calling non-function symbols in other sections
objtool: Ignore unreachable fake jumps
objtool: Remove useless tests before save_reg()
objtool: Decode unwind hint register depending on architecture
objtool: Make unwind hint definitions available to other architectures
objtool: Only include valid definitions depending on source file type
objtool: Rename frame.h -> objtool.h
objtool: Refactor jump table code to support other architectures
objtool: Make relocation in alternative handling arch dependent
objtool: Abstract alternative special case handling
objtool: Move macros describing structures to arch-dependent code
objtool: Make sync-check consider the target architecture
objtool: Group headers to check in a single list
objtool: Define 'struct orc_entry' only when needed
objtool: Skip ORC entry creation for non-text sections
objtool: Move ORC logic out of check()
...
13 Oct, 2020
3 commits
-
Pull static call support from Ingo Molnar:
"This introduces static_call(), which is the idea of static_branch()
applied to indirect function calls. Remove a data load (indirection)
by modifying the text.They give the flexibility of function pointers, but with better
performance. (This is especially important for cases where retpolines
would otherwise be used, as retpolines can be pretty slow.)API overview:
DECLARE_STATIC_CALL(name, func);
DEFINE_STATIC_CALL(name, func);
DEFINE_STATIC_CALL_NULL(name, typename);static_call(name)(args...);
static_call_cond(name)(args...);
static_call_update(name, func);x86 is supported via text patching, otherwise basic indirect calls are
used, with function pointers.There's a second variant using inline code patching, inspired by
jump-labels, implemented on x86 as well.The new APIs are utilized in the x86 perf code, a heavy user of
function pointers, where static calls speed up the PMU handler by
4.2% (!).The generic implementation is not really excercised on other
architectures, outside of the trivial test_static_call_init()
self-test"* tag 'core-static_call-2020-10-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (21 commits)
static_call: Fix return type of static_call_init
tracepoint: Fix out of sync data passing by static caller
tracepoint: Fix overly long tracepoint names
x86/perf, static_call: Optimize x86_pmu methods
tracepoint: Optimize using static_call()
static_call: Allow early init
static_call: Add some validation
static_call: Handle tail-calls
static_call: Add static_call_cond()
x86/alternatives: Teach text_poke_bp() to emulate RET
static_call: Add simple self-test for static calls
x86/static_call: Add inline static call implementation for x86-64
x86/static_call: Add out-of-line static call implementation
static_call: Avoid kprobes on inline static_call()s
static_call: Add inline static call infrastructure
static_call: Add basic static call infrastructure
compiler.h: Make __ADDRESSABLE() symbol truly unique
jump_label,module: Fix module lifetime for __jump_label_mod_text_reserved()
module: Properly propagate MODULE_STATE_COMING failure
module: Fix up module_notifier return values
... -
Pull locking updates from Ingo Molnar:
"These are the locking updates for v5.10:- Add deadlock detection for recursive read-locks.
The rationale is outlined in commit 224ec489d3cd ("lockdep/
Documention: Recursive read lock detection reasoning")The main deadlock pattern we want to detect is:
TASK A: TASK B:
read_lock(X);
write_lock(X);
read_lock_2(X);- Add "latch sequence counters" (seqcount_latch_t):
A sequence counter variant where the counter even/odd value is used
to switch between two copies of protected data. This allows the
read path, typically NMIs, to safely interrupt the write side
critical section.We utilize this new variant for sched-clock, and to make x86 TSC
handling safer.- Other seqlock cleanups, fixes and enhancements
- KCSAN updates
- LKMM updates
- Misc updates, cleanups and fixes"
* tag 'locking-core-2020-10-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (67 commits)
lockdep: Revert "lockdep: Use raw_cpu_*() for per-cpu variables"
lockdep: Fix lockdep recursion
lockdep: Fix usage_traceoverflow
locking/atomics: Check atomic-arch-fallback.h too
locking/seqlock: Tweak DEFINE_SEQLOCK() kernel doc
lockdep: Optimize the memory usage of circular queue
seqlock: Unbreak lockdep
seqlock: PREEMPT_RT: Do not starve seqlock_t writers
seqlock: seqcount_LOCKNAME_t: Introduce PREEMPT_RT support
seqlock: seqcount_t: Implement all read APIs as statement expressions
seqlock: Use unique prefix for seqcount_t property accessors
seqlock: seqcount_LOCKNAME_t: Standardize naming convention
seqlock: seqcount latch APIs: Only allow seqcount_latch_t
rbtree_latch: Use seqcount_latch_t
x86/tsc: Use seqcount_latch_t
timekeeping: Use seqcount_latch_t
time/sched_clock: Use seqcount_latch_t
seqlock: Introduce seqcount_latch_t
mm/swap: Do not abuse the seqcount_t latching API
time/sched_clock: Use raw_read_seqcount_latch() during suspend
... -
Pull RAS updates from Borislav Petkov:
- Extend the recovery from MCE in kernel space also to processes which
encounter an MCE in kernel space but while copying from user memory
by sending them a SIGBUS on return to user space and umapping the
faulty memory, by Tony Luck and Youquan Song.- memcpy_mcsafe() rework by splitting the functionality into
copy_mc_to_user() and copy_mc_to_kernel(). This, as a result, enables
support for new hardware which can recover from a machine check
encountered during a fast string copy and makes that the default and
lets the older hardware which does not support that advance recovery,
opt in to use the old, fragile, slow variant, by Dan Williams.- New AMD hw enablement, by Yazen Ghannam and Akshay Gupta.
- Do not use MSR-tracing accessors in #MC context and flag any fault
while accessing MCA architectural MSRs as an architectural violation
with the hope that such hw/fw misdesigns are caught early during the
hw eval phase and they don't make it into production.- Misc fixes, improvements and cleanups, as always.
* tag 'ras_updates_for_v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/mce: Allow for copy_mc_fragile symbol checksum to be generated
x86/mce: Decode a kernel instruction to determine if it is copying from user
x86/mce: Recover from poison found while copying from user space
x86/mce: Avoid tail copy when machine check terminated a copy from user
x86/mce: Add _ASM_EXTABLE_CPY for copy user access
x86/mce: Provide method to find out the type of an exception handler
x86/mce: Pass pointer to saved pt_regs to severity calculation routines
x86/copy_mc: Introduce copy_mc_enhanced_fast_string()
x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user, kernel}()
x86/mce: Drop AMD-specific "DEFERRED" case from Intel severity rule list
x86/mce: Add Skylake quirk for patrol scrub reported errors
RAS/CEC: Convert to DEFINE_SHOW_ATTRIBUTE()
x86/mce: Annotate mce_rd/wrmsrl() with noinstr
x86/mce/dev-mcelog: Do not update kflags on AMD systems
x86/mce: Stop mce_reign() from re-computing severity for every CPU
x86/mce: Make mce_rdmsrl() panic on an inaccessible MSR
x86/mce: Increase maximum number of banks to 64
x86/mce: Delay clearing IA32_MCG_STATUS to the end of do_machine_check()
x86/MCE/AMD, EDAC/mce_amd: Remove struct smca_hwid.xec_bitmap
RAS/CEC: Fix cec_init() prototype
09 Oct, 2020
1 commit
-
…nux-rcu into locking/core
Pull KCSAN updates for v5.10 from Paul E. McKenney:
- Improve kernel messages.
- Be more permissive with bitops races under KCSAN_ASSUME_PLAIN_WRITES_ATOMIC=y.
- Optimize debugfs stat counters.
- Introduce the instrument_*read_write() annotations, to provide a
finer description of certain ops - using KCSAN's compound instrumentation.
Use them for atomic RNW and bitops, where appropriate.
Doing this might find new races.
(Depends on the compiler having tsan-compound-read-before-write=1 support.)- Support atomic built-ins, which will help certain architectures, such as s390.
- Misc enhancements and smaller fixes.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
06 Oct, 2020
3 commits
-
Currently BUILD_BUG() macro is expanded to smth like the following:
do {
extern void __compiletime_assert_0(void)
__attribute__((error("BUILD_BUG failed")));
if (!(!(1)))
__compiletime_assert_0();
} while (0);If used in a function body this obviously would produce build errors
with -Wnested-externs and -Werror.Build objtool with -Wno-nested-externs to enable BUILD_BUG() usage.
Signed-off-by: Vasily Gorbik
Signed-off-by: Josh Poimboeuf -
The motivations to go rework memcpy_mcsafe() are that the benefit of
doing slow and careful copies is obviated on newer CPUs, and that the
current opt-in list of CPUs to instrument recovery is broken relative to
those CPUs. There is no need to keep an opt-in list up to date on an
ongoing basis if pmem/dax operations are instrumented for recovery by
default. With recovery enabled by default the old "mcsafe_key" opt-in to
careful copying can be made a "fragile" opt-out. Where the "fragile"
list takes steps to not consume poison across cachelines.The discussion with Linus made clear that the current "_mcsafe" suffix
was imprecise to a fault. The operations that are needed by pmem/dax are
to copy from a source address that might throw #MC to a destination that
may write-fault, if it is a user page.So copy_to_user_mcsafe() becomes copy_mc_to_user() to indicate
the separate precautions taken on source and destination.
copy_mc_to_kernel() is introduced as a non-SMAP version that does not
expect write-faults on the destination, but is still prepared to abort
with an error code upon taking #MC.The original copy_mc_fragile() implementation had negative performance
implications since it did not use the fast-string instruction sequence
to perform copies. For this reason copy_mc_to_kernel() fell back to
plain memcpy() to preserve performance on platforms that did not indicate
the capability to recover from machine check exceptions. However, that
capability detection was not architectural and now that some platforms
can recover from fast-string consumption of memory errors the memcpy()
fallback now causes these more capable platforms to fail.Introduce copy_mc_enhanced_fast_string() as the fast default
implementation of copy_mc_to_kernel() and finalize the transition of
copy_mc_fragile() to be a platform quirk to indicate 'copy-carefully'.
With this in place, copy_mc_to_kernel() is fast and recovery-ready by
default regardless of hardware capability.Thanks to Vivek for identifying that copy_user_generic() is not suitable
as the copy_mc_to_user() backend since the #MC handler explicitly checks
ex_has_fault_handler(). Thanks to the 0day robot for catching a
performance bug in the x86/copy_mc_to_user implementation.[ bp: Add the "why" for this change from the 0/2th message, massage. ]
Fixes: 92b0729c34ca ("x86/mm, x86/mce: Add memcpy_mcsafe()")
Reported-by: Erwin Tsaur
Reported-by: 0day robot
Signed-off-by: Dan Williams
Signed-off-by: Borislav Petkov
Reviewed-by: Tony Luck
Tested-by: Erwin Tsaur
Cc:
Link: https://lkml.kernel.org/r/160195562556.2163339.18063423034951948973.stgit@dwillia2-desk3.amr.corp.intel.com -
In reaction to a proposal to introduce a memcpy_mcsafe_fast()
implementation Linus points out that memcpy_mcsafe() is poorly named
relative to communicating the scope of the interface. Specifically what
addresses are valid to pass as source, destination, and what faults /
exceptions are handled.Of particular concern is that even though x86 might be able to handle
the semantics of copy_mc_to_user() with its common copy_user_generic()
implementation other archs likely need / want an explicit path for this
case:On Fri, May 1, 2020 at 11:28 AM Linus Torvalds wrote:
>
> On Thu, Apr 30, 2020 at 6:21 PM Dan Williams wrote:
> >
> > However now I see that copy_user_generic() works for the wrong reason.
> > It works because the exception on the source address due to poison
> > looks no different than a write fault on the user address to the
> > caller, it's still just a short copy. So it makes copy_to_user() work
> > for the wrong reason relative to the name.
>
> Right.
>
> And it won't work that way on other architectures. On x86, we have a
> generic function that can take faults on either side, and we use it
> for both cases (and for the "in_user" case too), but that's an
> artifact of the architecture oddity.
>
> In fact, it's probably wrong even on x86 - because it can hide bugs -
> but writing those things is painful enough that everybody prefers
> having just one function.Replace a single top-level memcpy_mcsafe() with either
copy_mc_to_user(), or copy_mc_to_kernel().Introduce an x86 copy_mc_fragile() name as the rename for the
low-level x86 implementation formerly named memcpy_mcsafe(). It is used
as the slow / careful backend that is supplanted by a fast
copy_mc_generic() in a follow-on patch.One side-effect of this reorganization is that separating copy_mc_64.S
to its own file means that perf no longer needs to track dependencies
for its memcpy_64.S benchmarks.[ bp: Massage a bit. ]
Signed-off-by: Dan Williams
Signed-off-by: Borislav Petkov
Reviewed-by: Tony Luck
Acked-by: Michael Ellerman
Cc:
Link: http://lore.kernel.org/r/CAHk-=wjSqtXAqfUJxFtWNwmguFASTgB0dz1dT3V-78Quiezqbg@mail.gmail.com
Link: https://lkml.kernel.org/r/160195561680.2163339.11574962055305783722.stgit@dwillia2-desk3.amr.corp.intel.com
02 Oct, 2020
1 commit
-
Building linux-next with JUMP_LABEL=n and KASAN=y, I got this objtool
warning:arch/x86/lib/copy_mc.o: warning: objtool: copy_mc_to_user()+0x22: call to
__kasan_check_read() with UACCESS enabledWhat happens here is that copy_mc_to_user() branches on a static key in a
UACCESS region:__uaccess_begin();
if (static_branch_unlikely(©_mc_fragile_key))
ret = copy_mc_fragile(to, from, len);
ret = copy_mc_generic(to, from, len);
__uaccess_end();and the !CONFIG_JUMP_LABEL version of static_branch_unlikely() uses
static_key_enabled(), which uses static_key_count(), which uses
atomic_read(), which calls instrument_atomic_read(), which uses
kasan_check_read(), which is __kasan_check_read().Let's permit these KASAN helpers in UACCESS regions - static keys should
probably work under UACCESS, I think.PeterZ adds:
It's not a matter of permitting, it's a matter of being safe and
correct. In this case it is, because it's a thin wrapper around
check_memory_region() which was already marked safe.check_memory_region() is correct because the only thing it ends up
calling is kasa_report() and that is also marked safe because that is
annotated with user_access_save/restore() before it does anything else.On top of that, all of KASAN is noinstr, so nothing in here will end up
in tracing and/or call schedule() before the user_access_save().Signed-off-by: Jann Horn
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Josh Poimboeuf
21 Sep, 2020
2 commits
-
With CONFIG_UBSAN_TRAP enabled, the compiler may insert a trap
instruction after a call to a noreturn function. In this case, objtool
warns that the UD2 instruction is unreachable.This is a behavior seen with Clang, from the oldest version capable of
building the mainline x64_64 kernel (9.0), to the latest experimental
version (12.0).Objtool silences similar warnings (trap after dead end instructions), so
so expand that check to include dead end functions.Cc: Nick Desaulniers
Cc: Rong Chen
Cc: Marco Elver
Cc: Philip Li
Cc: Borislav Petkov
Cc: kasan-dev@googlegroups.com
Cc: x86@kernel.org
Cc: clang-built-linux@googlegroups.com
BugLink: https://github.com/ClangBuiltLinux/linux/issues/1148
Link: https://lore.kernel.org/lkml/CAKwvOdmptEpi8fiOyWUo=AiZJiX+Z+VHJOM2buLPrWsMTwLnyw@mail.gmail.com
Suggested-by: Nick Desaulniers
Reviewed-by: Nick Desaulniers
Tested-by: Nick Desaulniers
Reported-by: kbuild test robot
Signed-off-by: Ilie Halip
Tested-by: Sedat Dilek
Signed-off-by: Josh Poimboeuf -
Relocation for a call destination could point to a symbol that has
type STT_NOTYPE.Lookup such a symbol when no function is available.
Signed-off-by: Julien Thierry
Signed-off-by: Josh Poimboeuf
19 Sep, 2020
3 commits
-
When a function is annotated with STACK_FRAME_NON_STANDARD, objtool
doesn't validate its code paths. It also skips sibling call detection
within the function.But sibling call detection is actually needed for the case where the
ignored function doesn't have any return instructions. Otherwise
objtool naively marks the function as implicit static noreturn, which
affects the reachability of its callers, resulting in "unreachable
instruction" warnings.Fix it by just enabling sibling call detection for ignored functions.
The 'insn->ignore' check in add_jump_destinations() is no longer needed
aftere6da9567959e ("objtool: Don't use ignore flag for fake jumps").
Fixes the following warning:
arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_handle_exit_irqoff()+0x142: unreachable instruction
which triggers on an allmodconfig with CONFIG_GCOV_KERNEL unset.
Reported-by: Linus Torvalds
Signed-off-by: Josh Poimboeuf
Signed-off-by: Borislav Petkov
Acked-by: Linus Torvalds
Link: https://lkml.kernel.org/r/5b1e2536cdbaa5246b60d7791b76130a74082c62.1599751464.git.jpoimboe@redhat.com -
It is possible for alternative code to unconditionally jump out of the
alternative region. In such a case, if a fake jump is added at the end
of the alternative instructions, the fake jump will never be reached.
Since the fake jump is just a mean to make sure code validation does not
go beyond the set of alternatives, reaching it is not a requirement.Signed-off-by: Julien Thierry
Signed-off-by: Josh Poimboeuf -
save_reg already checks that the register being saved does not already
have a saved state.Remove redundant checks before processing a register storing operation.
Signed-off-by: Julien Thierry
Signed-off-by: Josh Poimboeuf
10 Sep, 2020
8 commits
-
The set of registers that can be included in an unwind hint and their
encoding will depend on the architecture. Have arch specific code to
decode that register.Signed-off-by: Julien Thierry
Signed-off-by: Josh Poimboeuf -
Unwind hints are useful to provide objtool with information about stack
states in non-standard functions/code.While the type of information being provided might be very arch
specific, the mechanism to provide the information can be useful for
other architectures.Move the relevant unwint hint definitions for all architectures to
see.[ jpoimboe: REGS_IRET -> REGS_PARTIAL ]
Signed-off-by: Julien Thierry
Signed-off-by: Josh Poimboeuf -
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 -
Some alternatives associated with a specific feature need to be treated
in a special way. Since the features and how to treat them vary from one
architecture to another, move the special case handling to arch specific
code.Reviewed-by: Miroslav Benes
Signed-off-by: Julien Thierry
Signed-off-by: Josh Poimboeuf -
Some macros are defined to describe the size and layout of structures
exception_table_entry, jump_entry and alt_instr. These values can vary
from one architecture to another.Have the values be defined by arch specific code.
Suggested-by: Raphael Gault
Reviewed-by: Miroslav Benes
Signed-off-by: Julien Thierry
Signed-off-by: Josh Poimboeuf -
Do not take into account outdated headers unrelated to the build of the
current architecture.[ jpoimboe: use $SRCARCH directly ]
Reviewed-by: Miroslav Benes
Signed-off-by: Julien Thierry
Signed-off-by: Josh Poimboeuf -
In order to support multiple architectures and potentially different
sets of headers to compare against their kernel equivalent, it is
simpler to have all headers to check in a single list.Reviewed-by: Miroslav Benes
Signed-off-by: Julien Thierry
Signed-off-by: Josh Poimboeuf
02 Sep, 2020
4 commits
-
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 -
Orc generation is only done for text sections, but some instructions
can be found in non-text sections (e.g. .discard.text sections).Skip setting their orc sections since their whole sections will be
skipped for orc generation.Reviewed-by: Miroslav Benes
Signed-off-by: Julien Thierry
Signed-off-by: Josh Poimboeuf -
Now that the objtool_file can be obtained outside of the check function,
orc generation builtin no longer requires check to explicitly call its
orc related functions.Signed-off-by: Julien Thierry
Reviewed-by: Miroslav Benes
Signed-off-by: Josh Poimboeuf -
Structure objtool_file can be used by different subcommands. In fact
it already is, by check and orc.Provide a function that allows to initialize objtool_file, that builtin
can call, without relying on check to do the correct setup for them and
explicitly hand the objtool_file to them.Reviewed-by: Miroslav Benes
Signed-off-by: Julien Thierry
Signed-off-by: Josh Poimboeuf
01 Sep, 2020
2 commits
-
GCC can turn our static_call(name)(args...) into a tail call, in which
case we get a JMP.d32 into the trampoline (which then does a further
tail-call).Teach objtool to recognise and mark these in .static_call_sites and
adjust the code patching to deal with this.Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Ingo Molnar
Cc: Linus Torvalds
Link: https://lore.kernel.org/r/20200818135805.101186767@infradead.org -
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
25 Aug, 2020
2 commits
-
Adds the new __tsan_read_write compound instrumentation to objtool's
uaccess whitelist.Acked-by: Peter Zijlstra (Intel)
Cc: Josh Poimboeuf
Signed-off-by: Marco Elver
Signed-off-by: Paul E. McKenney -
Adds the new TSAN functions that may be emitted for atomic builtins to
objtool's uaccess whitelist.Signed-off-by: Marco Elver
Signed-off-by: Paul E. McKenney
Cc: Josh Poimboeuf
Cc: Peter Zijlstra
04 Aug, 2020
1 commit
-
Pull objtool updates from Ingo Molnar:
- Add support for non-rela relocations, in preparation to merge
'recordmcount' functionality into objtool- Fix assumption that broke under --ffunction-sections (LTO) builds
- Misc cleanups
* tag 'objtool-core-2020-08-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
objtool: Add support for relocations without addends
objtool: Rename rela to reloc
objtool: Use sh_info to find the base for .rela sections
objtool: Do not assume order of parent/child functions
29 Jun, 2020
1 commit
-
Pull objtool fixes from Borislav Petkov:
"Three fixes from Peter Zijlstra suppressing KCOV instrumentation in
noinstr sections.Peter Zijlstra says:
"Address KCOV vs noinstr. There is no function attribute to
selectively suppress KCOV instrumentation, instead teach objtool
to NOP out the calls in noinstr functions"This cures a bunch of KCOV crashes (as used by syzcaller)"
* tag 'objtool_urgent_for_5.8_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
objtool: Fix noinstr vs KCOV
objtool: Provide elf_write_{insn,reloc}()
objtool: Clean up elf_write() condition
25 Jun, 2020
1 commit
-
Avoids issuing C-file warnings for vmlinux.
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20200618144801.701257527@infradead.org
18 Jun, 2020
1 commit
-
Conflicts:
tools/objtool/elf.c
tools/objtool/elf.h
tools/objtool/orc_gen.c
tools/objtool/check.cSigned-off-by: Peter Zijlstra (Intel)