Hi all,

I know this is an old patch set, but I'm not able to see the context,
because I'm not subcribed to the ML.  For future patch sets can you also
add live-patching and lkml?

Are we still considering the shadow stack thing?  Just wondering why
we're talking about objtool again.

On Thu, Jan 28, 2021 at 02:22:50PM +0000, Mark Brown wrote:

On Wed, Jan 27, 2021 at 01:54:21PM -0600, Madhavan T. Venkataraman wrote:

quoted

Instead of failing the kernel build, can we just mark the functions as:

quoted

	FP	Functions that have proper FP code
	no-FP	Functions that don't

quoted

May be, we can add an "FP" flag in the symbol table entry for this.

quoted

Then, the unwinder can check the functions it encounters in the stack trace and
inform the caller if it found any no-FP functions. The caller of the unwinder can
decide what he wants to do with that information.

	- the caller can ignore it

	- the caller can print the stack trace with a warning that no-FP functions
	  were found

	- if the caller is livepatch, the caller can retry until the no-FP functions
	  disappear from the stack trace. This way, we can have live patching even
	  when some of the functions in the kernel are no-FP.

Does this make any sense? Is this acceptable? What are the pitfalls?

Why not just fix the reported no-FP functions?

quoted

If we can do this, the unwinder could detect cases such as:

quoted

- If gcc thinks that a function is a leaf function but the function contains
  inline assembly code that calls another function.

quoted

- If a call to a function bounces through some intermediate code such as a
  trampoline.

quoted

- etc.

quoted

For specific no-FP functions, the unwinder might be able to deduce the original
caller. In these cases, the stack trace would still be reliable. For all the others,
the stack trace would be considered unreliable.

I'm not entirely sure I see the distinction from the current situation
here?

quoted

Compiler instead of objtool
===========================

If the above suggestion is acceptable, I have another suggestion.

It is a lot of work for every new architecture to add frame pointer verification
support in objtool. Can we get some help from the compiler?

The compiler knows which C functions it generates the FP prolog and epilog for. It can
mark those functions as FP. As for assembly functions, kernel developers could manually
annotate functions that have proper FP code. The compiler/assembler would mark them
as FP. Only a small subset of assembly functions would even have FP prolog and epilog.

quoted

Is this acceptable? What are the pitfalls?

If we're trusting the compiler we can probably just do that without any
explicit support from the compiler - it should be doing the standard
stuff unless we explicitly ask it to and if it isn't then it might be a
result of a mismatch in assumptions rather than a deliberate decision to
do something non-standard.  My understanding with objtool is that a big
part of the idea is to provide a static check that the binary we end up
with matches the assumptions that we are making so the fact that it's a
separate implementation is important.

For C code, even if we trusted the compiler (which we don't), we still
have inline asm which the compiler doesn't have any visibility to, which
is more than capable of messing up frame pointers (we had several cases
of this in x86).

Getting the assembler to annotate which functions are FP could be
interesting but:

a) good luck getting the assembler folks to do that; they tend to be
   insistent on being ignorant of code semantics;

b) assembly often resembles spaghetti and the concept of a function is
   quite fluid; in fact many functions aren't annotated as such.

-- 
Josh


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel