linux-toradex.git/tools/objtool, branch v4.14-rc7

objtool: Fix memory leak in decode_instructions()

2017-10-20T07:43:21+00:00

When an error occurs before adding an allocated insn to the list, free
it before returning.

Signed-off-by: Kamalesh Babulal 
Signed-off-by: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/336da800bf6070eae11f4e0a3b9ca64c27658114.1508430423.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar

objtool: Support unoptimized frame pointer setup

2017-09-28T05:25:54+00:00

Arnd Bergmann reported a bunch of warnings like:

  crypto/jitterentropy.o: warning: objtool: jent_fold_time()+0x3b: call without frame pointer save/setup
  crypto/jitterentropy.o: warning: objtool: jent_stuck()+0x1d: call without frame pointer save/setup
  crypto/jitterentropy.o: warning: objtool: jent_unbiased_bit()+0x15: call without frame pointer save/setup
  crypto/jitterentropy.o: warning: objtool: jent_read_entropy()+0x32: call without frame pointer save/setup
  crypto/jitterentropy.o: warning: objtool: jent_entropy_collector_free()+0x19: call without frame pointer save/setup

and

  arch/x86/events/core.o: warning: objtool: collect_events uses BP as a scratch register
  arch/x86/events/core.o: warning: objtool: events_ht_sysfs_show()+0x22: call without frame pointer save/setup

With certain rare configurations, GCC sometimes sets up the frame
pointer with:

  lea    (%rsp),%rbp

instead of:

  mov    %rsp,%rbp

The instructions are equivalent, so treat the former like the latter.

Reported-by: Arnd Bergmann 
Signed-off-by: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/a468af8b28a69b83fffc6d7668be9b6fcc873699.1506526584.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar

x86/asm: Fix inline asm call constraints for Clang

2017-09-23T13:06:20+00:00

For inline asm statements which have a CALL instruction, we list the
stack pointer as a constraint to convince GCC to ensure the frame
pointer is set up first:

  static inline void foo()
  {
	register void *__sp asm(_ASM_SP);
	asm("call bar" : "+r" (__sp))
  }

Unfortunately, that pattern causes Clang to corrupt the stack pointer.

The fix is easy: convert the stack pointer register variable to a global
variable.

It should be noted that the end result is different based on the GCC
version.  With GCC 6.4, this patch has exactly the same result as
before:

	defconfig	defconfig-nofp	distro		distro-nofp
 before	9820389		9491555		8816046		8516940
 after	9820389		9491555		8816046		8516940

With GCC 7.2, however, GCC's behavior has changed.  It now changes its
behavior based on the conversion of the register variable to a global.
That somehow convinces it to *always* set up the frame pointer before
inserting *any* inline asm.  (Therefore, listing the variable as an
output constraint is a no-op and is no longer necessary.)  It's a bit
overkill, but the performance impact should be negligible.  And in fact,
there's a nice improvement with frame pointers disabled:

	defconfig	defconfig-nofp	distro		distro-nofp
 before	9796316		9468236		9076191		8790305
 after	9796957		9464267		9076381		8785949

So in summary, while listing the stack pointer as an output constraint
is no longer necessary for newer versions of GCC, it's still needed for
older versions.

Suggested-by: Andrey Ryabinin 
Reported-by: Matthias Kaehlcke 
Signed-off-by: Josh Poimboeuf 
Cc: Alexander Potapenko 
Cc: Andy Lutomirski 
Cc: Arnd Bergmann 
Cc: Dmitriy Vyukov 
Cc: Linus Torvalds 
Cc: Miguel Bernal Marin 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/3db862e970c432ae823cf515c52b54fec8270e0e.1505942196.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar

objtool: Handle another GCC stack pointer adjustment bug

2017-09-23T13:06:19+00:00

The kbuild bot reported the following warning with GCC 4.4 and a
randconfig:

  net/socket.o: warning: objtool: compat_sock_ioctl()+0x1083: stack state mismatch: cfa1=7+160 cfa2=-1+0

This is caused by another GCC non-optimization, where it backs up and
restores the stack pointer for no apparent reason:

    2f91:       48 89 e0                mov    %rsp,%rax
    2f94:       4c 89 e7                mov    %r12,%rdi
    2f97:       4c 89 f6                mov    %r14,%rsi
    2f9a:       ba 20 00 00 00          mov    $0x20,%edx
    2f9f:       48 89 c4                mov    %rax,%rsp

This issue would have been happily ignored before the following commit:

  dd88a0a0c861 ("objtool: Handle GCC stack pointer adjustment bug")

But now that objtool is paying attention to such stack pointer writes
to/from a register, it needs to understand them properly.  In this case
that means recognizing that the "mov %rsp, %rax" instruction is
potentially a backup of the stack pointer.

Reported-by: kbuild test robot 
Signed-off-by: Josh Poimboeuf 
Cc: Alexander Potapenko 
Cc: Andrey Ryabinin 
Cc: Andy Lutomirski 
Cc: Arnd Bergmann 
Cc: Dmitriy Vyukov 
Cc: Linus Torvalds 
Cc: Matthias Kaehlcke 
Cc: Miguel Bernal Marin 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Fixes: dd88a0a0c861 ("objtool: Handle GCC stack pointer adjustment bug")
Link: http://lkml.kernel.org/r/8c7aa8e9a36fbbb6655d9d8e7cea58958c912da8.1505942196.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar

objtool: Fix object file corruption

2017-09-15T09:31:57+00:00

Arnd Bergmann reported that a randconfig build was failing with the
following link error:

  built-in.o: member arch/x86/kernel/time.o in archive is not an object

It turns out the link failed because the time.o file had been corrupted
by objtool:

  nm: arch/x86/kernel/time.o: File format not recognized

In certain rare cases, when a .o file's ORC table is very small, the
.data section size doesn't change because it's page aligned.  Because
all the existing sections haven't changed size, libelf doesn't detect
any section header changes, and so it doesn't update the section header
table properly.  Instead it writes junk in the section header entries
for the new ORC sections.

Make sure libelf properly updates the section header table by setting
the ELF_F_DIRTY flag in the top level elf struct.

Reported-by: Arnd Bergmann 
Signed-off-by: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Fixes: 627fce14809b ("objtool: Add ORC unwind table generation")
Link: http://lkml.kernel.org/r/e650fd0f2d8a209d1409a9785deb101fdaed55fb.1505459813.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar

objtool: Do not retrieve data from empty sections

2017-09-15T09:31:50+00:00

Binutils 2.29-9 in Debian return an error when elf_getdata is invoked
on empty section (.note.GNU-stack in all kernel files), causing
immediate failure of kernel build with:

  elf_getdata: can't manipulate null section

As nothing is done with sections that have zero size, just do not
retrieve their data at all.

Signed-off-by: Petr Vandrovec 
Signed-off-by: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/2ce30a44349065b70d0f00e71e286dc0cbe745e6.1505459652.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar

objtool: Fix memory leak in elf_create_rela_section()

2017-09-15T09:31:43+00:00

Let's free the allocated char array 'relaname' before returning,
in order to avoid leaking memory.

Signed-off-by: Martin Kepplinger 
Acked-by: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: mingo.kernel.org@gmail.com
Link: http://lkml.kernel.org/r/20170914060138.26472-1-martink@posteo.de
Signed-off-by: Ingo Molnar

objtool: Handle GCC stack pointer adjustment bug

2017-08-30T08:48:41+00:00

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+120

Those 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, %rsp

Instead 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

objtool: Fix objtool fallthrough detection with function padding

2017-08-21T14:06:05+00:00

When GCC adds NOP padding between functions, those NOPs aren't
associated with a function symbol, which breaks objtool's detection of a
function falling through to another function.  Instead it shows
confusing errors like:

  drivers/mtd/chips/cfi_util.o: warning: objtool: cfi_qry_mode_on()+0x8b: return with modified stack frame
  drivers/mtd/chips/cfi_util.o: warning: objtool: cfi_qry_mode_on()+0x0: stack state mismatch: cfa1=-4-32 cfa2=7+8
  drivers/mtd/chips/cfi_cmdset_0002.o: warning: objtool: fixup_use_fwh_lock()+0x8: unknown stack-related register move
  drivers/mtd/chips/cfi_cmdset_0002.o: warning: objtool: fixup_use_fwh_lock()+0x0: stack state mismatch: cfa1=6+16 cfa2=7+8
  drivers/mtd/chips/cfi_cmdset_0002.o: warning: objtool: do_otp_write()+0xa: unsupported stack pointer realignment
  drivers/mtd/chips/cfi_cmdset_0002.o: warning: objtool: do_otp_write()+0x0: stack state mismatch: cfa1=-4-40 cfa2=7+8

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/43e7aae9a7a7710cd6df597fa9dc501da4ba0602.1502472193.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar

objtool: Track DRAP separately from callee-saved registers

2017-08-11T12:06:15+00:00

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
  retq

Since %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