From: Josh Poimboeuf <jpoimboe@redhat.com>
To: x86@kernel.org
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, Miroslav Benes <mbenes@suse.cz>
Subject: [PATCH 18/18] objtool: Update documentation
Date: Wed, 13 Apr 2022 16:19:53 -0700 [thread overview]
Message-ID: <b24f00f40327d50defa72a125a66100a79b5f716.1649891421.git.jpoimboe@redhat.com> (raw)
In-Reply-To: <cover.1649891421.git.jpoimboe@redhat.com>
The objtool documentation is very stack validation centric. Broaden the
documentation and describe all the features objtool supports.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
.../{stack-validation.txt => objtool.txt} | 122 +++++++++++++++---
1 file changed, 102 insertions(+), 20 deletions(-)
rename tools/objtool/Documentation/{stack-validation.txt => objtool.txt} (80%)
diff --git a/tools/objtool/Documentation/stack-validation.txt b/tools/objtool/Documentation/objtool.txt
similarity index 80%
rename from tools/objtool/Documentation/stack-validation.txt
rename to tools/objtool/Documentation/objtool.txt
index 30f38fdc0d56..8a671902a187 100644
--- a/tools/objtool/Documentation/stack-validation.txt
+++ b/tools/objtool/Documentation/objtool.txt
@@ -1,15 +1,103 @@
-Compile-time stack metadata validation
-======================================
+Objtool
+=======
+The kernel CONFIG_OBJTOOL option enables a host tool named 'objtool'
+which runs at compile time. It can do various validations and
+transformations on .o files.
-Overview
+Objtool has become an integral part of the x86-64 kernel toolchain. The
+kernel depends on it for a variety of security and performance features
+(and other types of features as well).
+
+
+Features
--------
-The kernel CONFIG_STACK_VALIDATION option enables a host tool named
-objtool which runs at compile time. It has a "check" subcommand which
-analyzes every .o file and ensures the validity of its stack metadata.
-It enforces a set of rules on asm code and C inline assembly code so
-that stack traces can be reliable.
+Objtool has the following features:
+
+- Stack unwinding metadata validation -- useful for helping to ensure
+ stack traces are reliable for live patching
+
+- ORC unwinder metadata generation -- a faster and more precise
+ alternative to frame pointer based unwinding
+
+- Retpoline validation -- ensures that all indirect calls go through
+ retpoline thunks, for Spectre v2 mitigations
+
+- Retpoline call site annotation -- annotates all retpoline thunk call
+ sites, enabling the kernel to patch them inline, to prevent "thunk
+ funneling" for both security and performance reasons
+
+- Non-instrumentation validation -- validates non-instrumentable
+ ("noinstr") code rules, preventing instrumentation in low-level C
+ entry code
+
+- Static call annotation -- annotates static call sites, enabling the
+ kernel to implement inline static calls, a faster alternative to some
+ indirect branches
+
+- Uaccess validation -- validates uaccess rules for a proper
+ implementation of Supervisor Mode Access Protection (SMAP)
+
+- Straight Line Speculation validation -- validates certain SLS
+ mitigations
+
+- Indirect Branch Tracking validation -- validates Intel CET IBT rules
+ to ensure that all functions referenced by function pointers have
+ corresponding ENDBR instructions
+
+- Indirect Branch Tracking annotation -- annotates unused ENDBR
+ instruction sites, enabling the kernel to "seal" them (replace them
+ with NOPs) to further harden IBT
+
+- Function entry annotation -- annotates function entries, enabling
+ kernel function tracing
+
+- Other toolchain hacks which will go unmentioned at this time...
+
+Each feature can be enabled individually or in combination using the
+objtool cmdline.
+
+
+Objects
+-------
+
+Typically, objtool runs on every translation unit (TU, aka ".o file") in
+the kernel. If a TU is part of a kernel module, the '--module' option
+is added.
+
+However:
+
+- If noinstr validation is enabled, it also runs on vmlinux.o, with all
+ options removed and '--noinstr' added.
+
+- If IBT or LTO is enabled, it doesn't run on TUs at all. Instead it
+ runs on vmlinux.o and linked modules, with all options.
+
+In summary:
+
+ A) Legacy mode:
+ TU: objtool [--module] <options>
+ vmlinux: N/A
+ module: N/A
+
+ B) CONFIG_NOINSTR_VALIDATION=y && !(CONFIG_X86_KERNEL_IBT=y || CONFIG_LTO=y):
+ TU: objtool [--module] <options> // no --noinstr
+ vmlinux: objtool --noinstr // other options removed
+ module: N/A
+
+ C) CONFIG_X86_KERNEL_IBT=y || CONFIG_LTO=y:
+ TU: N/A
+ vmlinux: objtool --noinstr <options>
+ module: objtool --module --noinstr <options>
+
+
+Stack validation
+----------------
+
+Objtool's stack validation feature analyzes every .o file and ensures
+the validity of its stack metadata. It enforces a set of rules on asm
+code and C inline assembly code so that stack traces can be reliable.
For each function, it recursively follows all possible code paths and
validates the correct frame pointer state at each instruction.
@@ -20,14 +108,6 @@ alternative execution paths to a given instruction (or set of
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.rst in the
-kernel tree for more details.)
-
-
-Why do we need stack metadata validation?
------------------------------------------
-
Here are some of the benefits of validating stack metadata:
a) More reliable stack traces for frame pointer enabled kernels
@@ -113,9 +193,6 @@ c) Higher live patching compatibility rate
For more details, see the livepatch documentation in the Linux kernel
source tree at Documentation/livepatch/livepatch.rst.
-Rules
------
-
To achieve the validation, objtool enforces the following rules:
1. Each callable function must be annotated as such with the ELF
@@ -177,7 +254,8 @@ 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.
+they mean, and suggestions for how to fix them. When in doubt, ping
+the objtool maintainers.
1. file.o: warning: objtool: func()+0x128: call without frame pointer save/setup
@@ -358,3 +436,7 @@ ignore it:
OBJECT_FILES_NON_STANDARD := y
to the Makefile.
+
+NOTE: OBJECT_FILES_NON_STANDARD doesn't work for link time validation of
+vmlinux.o or a linked module. So it should only be used for files which
+aren't linked into vmlinux or a module.
--
2.34.1
prev parent reply other threads:[~2022-04-13 23:21 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-13 23:19 [PATCH 00/18] objtool: Interface overhaul Josh Poimboeuf
2022-04-13 23:19 ` [PATCH 01/18] objtool: Enable unreachable warnings for CLANG LTO Josh Poimboeuf
2022-04-13 23:19 ` [PATCH 02/18] objtool: Support data symbol printing Josh Poimboeuf
2022-04-14 7:05 ` Peter Zijlstra
2022-04-14 15:21 ` Josh Poimboeuf
2022-04-14 15:31 ` Peter Zijlstra
2022-04-14 15:38 ` Josh Poimboeuf
2022-04-14 16:36 ` Peter Zijlstra
2022-04-14 17:01 ` Josh Poimboeuf
2022-04-14 17:21 ` Josh Poimboeuf
2022-04-13 23:19 ` [PATCH 03/18] objtool: Add sec+offset to warnings Josh Poimboeuf
2022-04-13 23:19 ` [PATCH 04/18] objtool: Print data address for "!ENDBR" data warnings Josh Poimboeuf
2022-04-14 7:36 ` Peter Zijlstra
2022-04-13 23:19 ` [PATCH 05/18] objtool: Use offstr() to print address of missing ENDBR Josh Poimboeuf
2022-04-13 23:19 ` [PATCH 06/18] libsubcmd: Fix OPTION_GROUP sorting Josh Poimboeuf
2022-04-13 23:19 ` [PATCH 07/18] objtool: Reorganize cmdline options Josh Poimboeuf
2022-04-13 23:19 ` [PATCH 08/18] objtool: Ditch subcommands Josh Poimboeuf
2022-04-13 23:19 ` [PATCH 09/18] objtool: Add stack validation cmdline option Josh Poimboeuf
2022-04-14 8:43 ` Peter Zijlstra
2022-04-14 15:52 ` Josh Poimboeuf
2022-04-13 23:19 ` [PATCH 10/18] objtool: Extricate ibt from stack validation Josh Poimboeuf
2022-04-14 7:53 ` Peter Zijlstra
2022-04-14 15:44 ` Josh Poimboeuf
2022-04-14 16:38 ` Peter Zijlstra
2022-04-14 17:05 ` Josh Poimboeuf
2022-04-14 18:25 ` Josh Poimboeuf
2022-04-14 19:01 ` Peter Zijlstra
2022-04-14 19:07 ` Josh Poimboeuf
2022-04-14 18:49 ` Peter Zijlstra
2022-04-13 23:19 ` [PATCH 11/18] objtool: Add CONFIG_OBJTOOL Josh Poimboeuf
2022-04-13 23:19 ` [PATCH 12/18] objtool: Make stack validation frame-pointer-specific Josh Poimboeuf
2022-04-13 23:19 ` [PATCH 13/18] objtool: Add static call cmdline option Josh Poimboeuf
2022-04-13 23:19 ` [PATCH 14/18] objtool: Add toolchain hacks " Josh Poimboeuf
2022-04-14 8:09 ` Peter Zijlstra
2022-04-14 15:49 ` Josh Poimboeuf
2022-04-13 23:19 ` [PATCH 15/18] objtool: Rename "VMLINUX_VALIDATION" -> "NOINSTR_VALIDATION" Josh Poimboeuf
2022-04-13 23:19 ` [PATCH 16/18] objtool: Add HAVE_NOINSTR_VALIDATION Josh Poimboeuf
2022-04-13 23:19 ` [PATCH 17/18] objtool: Remove --lto and --vmlinux Josh Poimboeuf
2022-04-14 8:13 ` Peter Zijlstra
2022-04-15 2:18 ` Josh Poimboeuf
2022-04-13 23:19 ` Josh Poimboeuf [this message]
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=b24f00f40327d50defa72a125a66100a79b5f716.1649891421.git.jpoimboe@redhat.com \
--to=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=peterz@infradead.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).