archive mirror
 help / color / mirror / Atom feed
* [RFC] Objtool toolchain proposal: -fannotate-{jump-table,noreturn}
@ 2022-09-09 18:07 Josh Poimboeuf
  2022-09-11 15:26 ` Peter Zijlstra
                   ` (3 more replies)
  0 siblings, 4 replies; 20+ messages in thread
From: Josh Poimboeuf @ 2022-09-09 18:07 UTC (permalink / raw)
  To: linux-toolchains
  Cc: Peter Zijlstra, Indu Bhagat, Nick Desaulniers, linux-kernel,
	Jose E. Marchesi, Miroslav Benes, Mark Rutland, Will Deacon, x86,
	linux-arm-kernel, live-patching, linuxppc-dev, Ard Biesheuvel,
	Chen Zhongjin, Sathvika Vasireddy, Christophe Leroy, Mark Brown


Here's a preview of what I'm planning to discuss at the LPC toolchains
microconference.  Feel free to start the discussion early :-)

This is a proposal for some new minor GCC/Clang features which would
help objtool greatly.


Objtool is a kernel-specific tool which reverse engineers the control
flow graph (CFG) of compiled objects.  It then performs various
validations, annotations, and modifications, mostly with the goal of
improving robustness and security of the kernel.

Objtool features which use the CFG include include:
validation/generation of unwinding metadata; validation of Intel SMAP
rules; and validation of kernel "noinstr" rules (preventing compiler
instrumentation in certain critical sections).

In general it's not feasible for the traditional toolchain to do any of
this work, because the kernel has a lot of "blind spots" which the
toolchain doesn't have visibility to, notably asm and inline asm.
Manual .cfi annotations are very difficult to maintain and even more
difficult to ensure correctness.  Also, due to kernel live patching, the
kernel relies on 100% correctness of unwinding metadata, whereas the
toolchain treats it as a best effort.


Reverse engineering the control flow graph is mostly quite
straightforward, with two notable exceptions:

1) Jump tables (e.g., switch statements):

   Depending on the architecture, it's somewhere between difficult and
   impossible to reliabily identify which indirect jumps correspond to
   jump tables, and what are their corresponding intra-function jump

2) Noreturn functions:
   There's no reliable way to determine which functions are designated
   by the compiler to be noreturn (either explictly via function
   attribute, or implicitly via a static function which is a wrapper
   around a noreturn function.)  This information is needed because the
   code after the call to such a function is optimized out as
   unreachable and objtool has no way of knowing that.


Add the following new compiler flags which create non-allocatable ELF
sections which "annotate" control flow:

(Note this is purely hypothetical, intended for starting a discussion.
I'm not a compiler person and I haven't written any compiler code.)

1) -fannotate-jump-table

Create an .annotate.jump_table section which is an array of the
following variable-length structure:

  struct annotate_jump_table {
	void *indirect_jmp;
	long num_targets;
	void *targets[];

For example, given the following switch statement code:

	// %rax is .Lcase_1 or .Lcase_2
	jmp %rax


Add the following code:

  .pushsection .annotate.jump_table
	// indirect JMP address
	.quad .Lswitch_jmp

	// num jump targets
	.quad 2

	// indirect JMP target addresses
	.quad .Lcase_1
	.quad .Lcase_2

2) -fannotate-noreturn

Create an .annotate.noreturn section which is an array of pointers to
noreturn functions (both explicit/implicit and defined/undefined).

For example, given the following three noreturn functions:

  // explicit noreturn:
  __attribute__((__noreturn__)) void func1(void)

  // explicit noreturn (extern):
  extern __attribute__((__noreturn__)) void func2(void);

  // implicit noreturn:
  static void func3(void)
  	// call noreturn function

Add the following code:

  .pushsection .annotate.noreturn
	.quad func1
	.quad func2
	.quad func3


Another idea which has been floated in the past is for objtool to read
DWARF (or .eh_frame) to help it figure out the control flow.  That
hasn't been tried yet, but would be considerably more difficult and
fragile IMO.


^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2022-09-21  3:16 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-09 18:07 [RFC] Objtool toolchain proposal: -fannotate-{jump-table,noreturn} Josh Poimboeuf
2022-09-11 15:26 ` Peter Zijlstra
2022-09-11 15:31   ` Ard Biesheuvel
2022-09-12 10:52 ` Borislav Petkov
2022-09-12 14:17   ` Michael Matz
2022-09-14  0:04     ` Josh Poimboeuf
2022-09-14 14:00       ` Peter Zijlstra
2022-09-14 14:28         ` Michael Matz
2022-09-14 14:55           ` Peter Zijlstra
2022-09-14 17:34             ` Segher Boessenkool
2022-09-15  2:56     ` Chen Zhongjin
2022-09-15  8:47       ` Peter Zijlstra
2022-09-20 16:49         ` Ard Biesheuvel
2022-09-21  3:16           ` Chen Zhongjin
2022-09-12 11:31 ` Segher Boessenkool
2022-09-14 10:21   ` Josh Poimboeuf
2022-09-14 12:08     ` Michael Matz
2022-09-14 12:16     ` Segher Boessenkool
2022-09-13 22:51 ` Indu Bhagat
2022-09-14  0:12   ` Josh Poimboeuf

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).