objtool: sync up with the 4.14.47 version of objtool

/*

 * Copyright (C) 2017 Josh Poimboeuf <jpoimboe@redhat.com>

 *

 * 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/licenses/>.

 */

#ifndef _ORC_TYPES_H

#define _ORC_TYPES_H

#include <linux/types.h>

#include <linux/compiler.h>

/*

 * The ORC_REG_* registers are base registers which are used to find other

 * registers on the stack.

 *

 * ORC_REG_PREV_SP, also known as DWARF Call Frame Address (CFA), is the

 * address of the previous frame: the caller's SP before it called the current

 * function.

 *

 * ORC_REG_UNDEFINED means the corresponding register's value didn't change in

 * the current frame.

 *

 * The most commonly used base registers are SP and BP -- which the previous SP

 * is usually based on -- and PREV_SP and UNDEFINED -- which the previous BP is

 * usually based on.

 *

 * The rest of the base registers are needed for special cases like entry code

 * and GCC realigned stacks.

 */

#define ORC_REG_UNDEFINED		0

#define ORC_REG_PREV_SP			1

#define ORC_REG_DX			2

#define ORC_REG_DI			3

#define ORC_REG_BP			4

#define ORC_REG_SP			5

#define ORC_REG_R10			6

#define ORC_REG_R13			7

#define ORC_REG_BP_INDIRECT		8

#define ORC_REG_SP_INDIRECT		9

#define ORC_REG_MAX			15

/*

 * ORC_TYPE_CALL: Indicates that sp_reg+sp_offset resolves to PREV_SP (the

 * caller's SP right before it made the call).  Used for all callable

 * functions, i.e. all C code and all callable asm functions.

 *

 * ORC_TYPE_REGS: Used in entry code to indicate that sp_reg+sp_offset points

 * to a fully populated pt_regs from a syscall, interrupt, or exception.

 *

 * ORC_TYPE_REGS_IRET: Used in entry code to indicate that sp_reg+sp_offset

 * points to the iret return frame.

 *

 * The UNWIND_HINT macros are used only for the unwind_hint struct.  They

 * aren't used in struct orc_entry due to size and complexity constraints.

 * Objtool converts them to real types when it converts the hints to orc

 * entries.

 */

#define ORC_TYPE_CALL			0

#define ORC_TYPE_REGS			1

#define ORC_TYPE_REGS_IRET		2

#define UNWIND_HINT_TYPE_SAVE		3

#define UNWIND_HINT_TYPE_RESTORE	4

#ifndef __ASSEMBLY__

/*

 * This struct is more or less a vastly simplified version of the DWARF Call

 * Frame Information standard.  It contains only the necessary parts of DWARF

 * CFI, simplified for ease of access by the in-kernel unwinder.  It tells the

 * unwinder how to find the previous SP and BP (and sometimes entry regs) on

 * the stack for a given code address.  Each instance of the struct corresponds

 * to one or more code locations.

 */

struct orc_entry {

	s16		sp_offset;

	s16		bp_offset;

	unsigned	sp_reg:4;

	unsigned	bp_reg:4;

	unsigned	type:2;

};

/*

 * This struct is used by asm and inline asm code to manually annotate the

 * location of registers on the stack for the ORC unwinder.

 *

 * Type can be either ORC_TYPE_* or UNWIND_HINT_TYPE_*.

 */

struct unwind_hint {

	u32		ip;

	s16		sp_offset;

	u8		sp_reg;

	u8		type;

};

#endif /* __ASSEMBLY__ */

#endif /* _ORC_TYPES_H */

#ifndef _ASM_X86_UNWIND_HINTS_H

#define _ASM_X86_UNWIND_HINTS_H

#include "orc_types.h"

#ifdef __ASSEMBLY__

/*

 * In asm, there are two kinds of code: normal C-type callable functions and

 * the rest.  The normal callable functions can be called by other code, and

 * don't do anything unusual with the stack.  Such normal callable functions

 * are annotated with the ENTRY/ENDPROC macros.  Most asm code falls in this

 * category.  In this case, no special debugging annotations are needed because

 * objtool can automatically generate the ORC data for the ORC unwinder to read

 * at runtime.

 *

 * Anything which doesn't fall into the above category, such as syscall and

 * interrupt handlers, tends to not be called directly by other functions, and

 * often does unusual non-C-function-type things with the stack pointer.  Such

 * code needs to be annotated such that objtool can understand it.  The

 * following CFI hint macros are for this type of code.

 *

 * These macros provide hints to objtool about the state of the stack at each

 * instruction.  Objtool starts from the hints and follows the code flow,

 * making automatic CFI adjustments when it sees pushes and pops, filling out

 * the debuginfo as necessary.  It will also warn if it sees any

 * inconsistencies.

 */

.macro UNWIND_HINT sp_reg=ORC_REG_SP sp_offset=0 type=ORC_TYPE_CALL

#ifdef CONFIG_STACK_VALIDATION

.Lunwind_hint_ip_\@:

	.pushsection .discard.unwind_hints

		/* struct unwind_hint */

		.long .Lunwind_hint_ip_\@ - .

		.short \sp_offset

		.byte \sp_reg

		.byte \type

	.popsection

#endif

.endm

.macro UNWIND_HINT_EMPTY

	UNWIND_HINT sp_reg=ORC_REG_UNDEFINED

.endm

.macro UNWIND_HINT_REGS base=%rsp offset=0 indirect=0 extra=1 iret=0

	.if \base == %rsp && \indirect

		.set sp_reg, ORC_REG_SP_INDIRECT

	.elseif \base == %rsp

		.set sp_reg, ORC_REG_SP

	.elseif \base == %rbp

		.set sp_reg, ORC_REG_BP

	.elseif \base == %rdi

		.set sp_reg, ORC_REG_DI

	.elseif \base == %rdx

		.set sp_reg, ORC_REG_DX

	.elseif \base == %r10

		.set sp_reg, ORC_REG_R10

	.else

		.error "UNWIND_HINT_REGS: bad base register"

	.endif

	.set sp_offset, \offset

	.if \iret

		.set type, ORC_TYPE_REGS_IRET

	.elseif \extra == 0

		.set type, ORC_TYPE_REGS_IRET

		.set sp_offset, \offset + (16*8)

	.else

		.set type, ORC_TYPE_REGS

	.endif

	UNWIND_HINT sp_reg=sp_reg sp_offset=sp_offset type=type

.endm

.macro UNWIND_HINT_IRET_REGS base=%rsp offset=0

	UNWIND_HINT_REGS base=\base offset=\offset iret=1

.endm

.macro UNWIND_HINT_FUNC sp_offset=8

	UNWIND_HINT sp_offset=\sp_offset

.endm

#else /* !__ASSEMBLY__ */

#define UNWIND_HINT(sp_reg, sp_offset, type)			\

	"987: \n\t"						\

	".pushsection .discard.unwind_hints\n\t"		\

	/* struct unwind_hint */				\

	".long 987b - .\n\t"					\

	".short " __stringify(sp_offset) "\n\t"		\

	".byte " __stringify(sp_reg) "\n\t"			\

	".byte " __stringify(type) "\n\t"			\

	".popsection\n\t"

#define UNWIND_HINT_SAVE UNWIND_HINT(0, 0, UNWIND_HINT_TYPE_SAVE)

#define UNWIND_HINT_RESTORE UNWIND_HINT(0, 0, UNWIND_HINT_TYPE_RESTORE)

#endif /* __ASSEMBLY__ */

#endif /* _ASM_X86_UNWIND_HINTS_H */

objtool-y += arch/$(SRCARCH)/

objtool-y += builtin-check.o

objtool-y += builtin-orc.o

objtool-y += check.o

objtool-y += orc_gen.o

objtool-y += orc_dump.o

objtool-y += elf.o

objtool-y += special.o

objtool-y += objtool.o

It enforces a set of rules on asm code and C inline assembly code so

that stack traces can be reliable.

Currently it only checks frame pointer usage, but there are plans to add

CFI validation for C files and CFI generation for asm files.

For each function, it recursively follows all possible code paths and

validates the correct frame pointer state at each instruction.

instructions).  Similarly, it knows how to follow switch statements, for

which gcc sometimes uses jump tables.

(Objtool also has an 'orc generate' subcommand which generates debuginfo

for the ORC unwinder.  See Documentation/x86/orc-unwinder.txt in the

kernel tree for more details.)

Why do we need stack metadata validation?

-----------------------------------------

       or at the very end of the function after the stack frame has been

       destroyed.  This is an inherent limitation of frame pointers.

b) 100% reliable stack traces for DWARF enabled kernels

   (NOTE: This is not yet implemented)

   As an alternative to frame pointers, DWARF Call Frame Information

   (CFI) metadata can be used to walk the stack.  Unlike frame pointers,

   CFI metadata is out of band.  So it doesn't affect runtime

   performance and it can be reliable even when interrupts or exceptions

   are involved.

   For C code, gcc automatically generates DWARF CFI metadata.  But for

   asm code, generating CFI is a tedious manual approach which requires

   manually placed .cfi assembler macros to be scattered throughout the

   code.  It's clumsy and very easy to get wrong, and it makes the real

   code harder to read.

   Stacktool will improve this situation in several ways.  For code

   which already has CFI annotations, it will validate them.  For code

   which doesn't have CFI annotations, it will generate them.  So an

   architecture can opt to strip out all the manual .cfi annotations

   from their asm code and have objtool generate them instead.

b) ORC (Oops Rewind Capability) unwind table generation

   We might also add a runtime stack validation debug option where we

   periodically walk the stack from schedule() and/or an NMI to ensure

   that the stack metadata is sane and that we reach the bottom of the

   stack.

   An alternative to frame pointers and DWARF, ORC unwind data can be

   used to walk the stack.  Unlike frame pointers, ORC data is out of

   band.  So it doesn't affect runtime performance and it can be

   reliable even when interrupts or exceptions are involved.

   So the benefit of objtool here will be that external tooling should

   always show perfect stack traces.  And the same will be true for

   kernel warning/oops traces if the architecture has a runtime DWARF

   unwinder.

   For more details, see Documentation/x86/orc-unwinder.txt.

c) Higher live patching compatibility rate

   (NOTE: This is not yet implemented)

   Currently with CONFIG_LIVEPATCH there's a basic live patching

   framework which is safe for roughly 85-90% of "security" fixes.  But

   patches can't have complex features like function dependency or

   prototype changes, or data structure changes.

   There's a strong need to support patches which have the more complex

   features so that the patch compatibility rate for security fixes can

   eventually approach something resembling 100%.  To achieve that, a

   "consistency model" is needed, which allows tasks to be safely

   transitioned from an unpatched state to a patched state.

   One of the key requirements of the currently proposed livepatch

   consistency model [*] is that it needs to walk the stack of each

   sleeping task to determine if it can be transitioned to the patched

   state.  If objtool can ensure that stack traces are reliable, this

   consistency model can be used and the live patching compatibility

   rate can be improved significantly.

   [*] https://lkml.kernel.org/r/cover.1423499826.git.jpoimboe@redhat.com

   Livepatch has an optional "consistency model", which is needed for

   more complex patches.  In order for the consistency model to work,

   stack traces need to be reliable (or an unreliable condition needs to

   be detectable).  Objtool makes that possible.

   For more details, see the livepatch documentation in the Linux kernel

   source tree at Documentation/livepatch/livepatch.txt.

Rules

-----

   return normally.

Errors in .S files

------------------

Objtool warnings

----------------

For asm files, if you're getting an error which doesn't make sense,

first make sure that the affected code follows the above rules.

If you're getting an error in a compiled .S file which you don't

understand, first make sure that the affected code follows the above

rules.

For C files, the common culprits are inline asm statements and calls to

"noreturn" functions.  See below for more details.

Another possible cause for errors in C code is if the Makefile removes

-fno-omit-frame-pointer or adds -fomit-frame-pointer to the gcc options.

Here are some examples of common warnings reported by objtool, what

they mean, and suggestions for how to fix them.

1. asm_file.o: warning: objtool: func()+0x128: call without frame pointer save/setup

1. file.o: warning: objtool: func()+0x128: call without frame pointer save/setup

   The func() function made a function call without first saving and/or

   updating the frame pointer.

   If func() is indeed a callable function, add proper frame pointer

   logic using the FRAME_BEGIN and FRAME_END macros.  Otherwise, remove

   its ELF function annotation by changing ENDPROC to END.

   If you're getting this error in a .c file, see the "Errors in .c

   files" section.

   updating the frame pointer, and CONFIG_FRAME_POINTER is enabled.

   If the error is for an asm file, and func() is indeed a callable

   function, add proper frame pointer logic using the FRAME_BEGIN and

   FRAME_END macros.  Otherwise, if it's not a callable function, remove

   its ELF function annotation by changing ENDPROC to END, and instead

   use the manual unwind hint macros in asm/unwind_hints.h.

2. asm_file.o: warning: objtool: .text+0x53: return instruction outside of a callable function

   If it's a GCC-compiled .c file, the error may be because the function

   uses an inline asm() statement which has a "call" instruction.  An

   asm() statement with a call instruction must declare the use of the

   stack pointer in its output operand.  On x86_64, this means adding

   the ASM_CALL_CONSTRAINT as an output constraint:

   A return instruction was detected, but objtool couldn't find a way

   for a callable function to reach the instruction.

     asm volatile("call func" : ASM_CALL_CONSTRAINT);

   If the return instruction is inside (or reachable from) a callable

   function, the function needs to be annotated with the ENTRY/ENDPROC

   macros.

   Otherwise the stack frame may not get created before the call.

   If you _really_ need a return instruction outside of a function, and

   are 100% sure that it won't affect stack traces, you can tell

   objtool to ignore it.  See the "Adding exceptions" section below.

2. file.o: warning: objtool: .text+0x53: unreachable instruction

3. asm_file.o: warning: objtool: func()+0x9: function has unreachable instruction

   Objtool couldn't find a code path to reach the instruction.

   The instruction lives inside of a callable function, but there's no

   possible control flow path from the beginning of the function to the

   instruction.

   If the error is for an asm file, and the instruction is inside (or

   reachable from) a callable function, the function should be annotated

   with the ENTRY/ENDPROC macros (ENDPROC is the important one).

   Otherwise, the code should probably be annotated with the unwind hint

   macros in asm/unwind_hints.h so objtool and the unwinder can know the

   stack state associated with the code.

   If the instruction is actually needed, and it's actually in a

   callable function, ensure that its function is properly annotated

   with ENTRY/ENDPROC.

   If you're 100% sure the code won't affect stack traces, or if you're

   a just a bad person, you can tell objtool to ignore it.  See the

   "Adding exceptions" section below.

   If it's not actually in a callable function (e.g. kernel entry code),

   change ENDPROC to END.

4. asm_file.o: warning: objtool: func(): can't find starting instruction

4. file.o: warning: objtool: func(): can't find starting instruction

   or

   asm_file.o: warning: objtool: func()+0x11dd: can't decode instruction

   file.o: warning: objtool: func()+0x11dd: can't decode instruction

   Did you put data in a text section?  If so, that can confuse

   Does the file have data in a text section?  If so, that can confuse

   objtool's instruction decoder.  Move the data to a more appropriate

   section like .data or .rodata.

5. asm_file.o: warning: objtool: func()+0x6: kernel entry/exit from callable instruction

   This is a kernel entry/exit instruction like sysenter or sysret.

   Such instructions aren't allowed in a callable function, and are most

   likely part of the kernel entry code.

5. file.o: warning: objtool: func()+0x6: unsupported instruction in callable function

   If the instruction isn't actually in a callable function, change

   ENDPROC to END.

   This is a kernel entry/exit instruction like sysenter or iret.  Such

   instructions aren't allowed in a callable function, and are most

   likely part of the kernel entry code.  They should usually not have

   the callable function annotation (ENDPROC) and should always be

   annotated with the unwind hint macros in asm/unwind_hints.h.

6. asm_file.o: warning: objtool: func()+0x26: sibling call from callable instruction with changed frame pointer

6. file.o: warning: objtool: func()+0x26: sibling call from callable instruction with modified stack frame

   This is a dynamic jump or a jump to an undefined symbol.  Stacktool

   This is a dynamic jump or a jump to an undefined symbol.  Objtool

   assumed it's a sibling call and detected that the frame pointer

   wasn't first restored to its original state.

   destination code to the local file.

   If the instruction is not actually in a callable function (e.g.

   kernel entry code), change ENDPROC to END.

   kernel entry code), change ENDPROC to END and annotate manually with

   the unwind hint macros in asm/unwind_hints.h.

7. asm_file: warning: objtool: func()+0x5c: frame pointer state mismatch

7. file: warning: objtool: func()+0x5c: stack state mismatch

   The instruction's frame pointer state is inconsistent, depending on

   which execution path was taken to reach the instruction.

   Make sure the function pushes and sets up the frame pointer (for

   x86_64, this means rbp) at the beginning of the function and pops it

   at the end of the function.  Also make sure that no other code in the

   function touches the frame pointer.

   Make sure that, when CONFIG_FRAME_POINTER is enabled, the function

   pushes and sets up the frame pointer (for x86_64, this means rbp) at

   the beginning of the function and pops it at the end of the function.

   Also make sure that no other code in the function touches the frame

   pointer.

   Another possibility is that the code has some asm or inline asm which

   does some unusual things to the stack or the frame pointer.  In such

   cases it's probably appropriate to use the unwind hint macros in

   asm/unwind_hints.h.

Errors in .c files

------------------

1. c_file.o: warning: objtool: funcA() falls through to next function funcB()

8. file.o: warning: objtool: funcA() falls through to next function funcB()

   This means that funcA() doesn't end with a return instruction or an

   unconditional jump, and that objtool has determined that the function

      might be corrupt due to a gcc bug.  For more details, see:

      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646

2. If you're getting any other objtool error in a compiled .c file, it

   may be because the file uses an asm() statement which has a "call"

   instruction.  An asm() statement with a call instruction must declare

   the use of the stack pointer in its output operand.  For example, on

   x86_64:

     register void *__sp asm("rsp");

     asm volatile("call func" : "+r" (__sp));

   Otherwise the stack frame may not get created before the call.

3. Another possible cause for errors in C code is if the Makefile removes

   -fno-omit-frame-pointer or adds -fomit-frame-pointer to the gcc options.

Also see the above section for .S file errors for more information what

the individual error messages mean.

If the error doesn't seem to make sense, it could be a bug in objtool.

Feel free to ask the objtool maintainer for help.

# SPDX-License-Identifier: GPL-2.0

include ../scripts/Makefile.include

include ../scripts/Makefile.arch

endif

# always use the host compiler

CC = gcc

LD = ld

HOSTCC	?= gcc

HOSTLD	?= ld

CC	 = $(HOSTCC)

LD	 = $(HOSTLD)

AR	 = ar

ifeq ($(srctree),)

srctree := $(patsubst %/,%,$(dir $(shell pwd)))

srctree := $(patsubst %/,%,$(dir $(CURDIR)))

srctree := $(patsubst %/,%,$(dir $(srctree)))

endif

SUBCMD_SRCDIR		= $(srctree)/tools/lib/subcmd/

LIBSUBCMD_OUTPUT	= $(if $(OUTPUT),$(OUTPUT),$(PWD)/)

LIBSUBCMD_OUTPUT	= $(if $(OUTPUT),$(OUTPUT),$(CURDIR)/)

LIBSUBCMD		= $(LIBSUBCMD_OUTPUT)libsubcmd.a

OBJTOOL    := $(OUTPUT)objtool

all: $(OBJTOOL)

INCLUDES := -I$(srctree)/tools/include -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi

CFLAGS   += -Wall -Werror $(EXTRA_WARNINGS) -fomit-frame-pointer -O2 -g $(INCLUDES)

INCLUDES := -I$(srctree)/tools/include \

	    -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \

	    -I$(srctree)/tools/objtool/arch/$(ARCH)/include

WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed

CFLAGS   += -Wall -Werror $(WARNINGS) -fomit-frame-pointer -O2 -g $(INCLUDES)

LDFLAGS  += -lelf $(LIBSUBCMD)

# Allow old libelf to be used:

$(OBJTOOL_IN): fixdep FORCE

	@$(MAKE) $(build)=objtool

# Busybox's diff doesn't have -I, avoid warning in that case

#

$(OBJTOOL): $(LIBSUBCMD) $(OBJTOOL_IN)

	@(diff -I 2>&1 | grep -q 'option requires an argument' && \

	test -d ../../kernel -a -d ../../tools -a -d ../objtool && (( \

	diff -I'^#include' arch/x86/insn/insn.c ../../arch/x86/lib/insn.c >/dev/null && \

	diff -I'^#include' arch/x86/insn/inat.c ../../arch/x86/lib/inat.c >/dev/null && \

	diff arch/x86/insn/x86-opcode-map.txt ../../arch/x86/lib/x86-opcode-map.txt >/dev/null && \

	diff arch/x86/insn/gen-insn-attr-x86.awk ../../arch/x86/tools/gen-insn-attr-x86.awk >/dev/null && \

	diff -I'^#include' arch/x86/insn/insn.h ../../arch/x86/include/asm/insn.h >/dev/null && \

	diff -I'^#include' arch/x86/insn/inat.h ../../arch/x86/include/asm/inat.h >/dev/null && \

	diff -I'^#include' arch/x86/insn/inat_types.h ../../arch/x86/include/asm/inat_types.h >/dev/null) \

	|| echo "warning: objtool: x86 instruction decoder differs from kernel" >&2 )) || true

	@$(CONFIG_SHELL) ./sync-check.sh

	$(QUIET_LINK)$(CC) $(OBJTOOL_IN) $(LDFLAGS) -o $@

clean:

	$(call QUIET_CLEAN, objtool) $(RM) $(OBJTOOL)

	$(Q)find $(OUTPUT) -name '*.o' -delete -o -name '\.*.cmd' -delete -o -name '\.*.d' -delete

	$(Q)$(RM) $(OUTPUT)arch/x86/insn/inat-tables.c $(OUTPUT)fixdep

	$(Q)$(RM) $(OUTPUT)arch/x86/lib/inat-tables.c $(OUTPUT)fixdep

FORCE: