On Wed, Jan 13, 2021 at 08:23:15PM +0000, Mark Brown wrote:

On Wed, Jan 13, 2021 at 01:33:13PM -0600, Josh Poimboeuf wrote:

quoted

I think it's worth mentioning a little more about objtool.  There are a
few passing mentions of objtool's generation of metadata (i.e. ORC), but
objtool has another relevant purpose: stack validation.  That's
particularly important when it comes to frame pointers.

quoted

For some architectures like x86_64 and arm64 (but not powerpc/s390),
it's far too easy for a human to write asm and/or inline asm which
violates frame pointer protocol, silently causing the violater's callee
to get skipped in the unwind.  Such architectures need objtool
implemented for CONFIG_STACK_VALIDATION.

This basically boils down to just adding a statement saying "you may
need to depend on objtool" I think?

Right, but maybe it would be a short paragraph or two.

quoted

quoted

+There are several ways an architecture may identify kernel code which is deemed
+unreliable to unwind from, e.g.

quoted

quoted

+* Using metadata created by objtool, with such code annotated with
+  SYM_CODE_{START,END} or STACKFRAME_NON_STANDARD().

quoted

I'm not sure why SYM_CODE_{START,END} is mentioned here, but it doesn't
necessarily mean the code is unreliable, and objtool doesn't treat it as
such.  Its mention can probably be removed unless there was some other
point I'm missing.

I was reading that as being a thing that the architecture could possibly
do, especially as a first step - it does seem like a reasonable thing to
consider using anyway.  I guess you could also use it the other way
around and do additional checks for things that are supposed to be
regular functions that you relax for SYM_CODE() sections.

Makes sense, but we have to be careful not to imply that objtool already
does something like that :-)

-- 
Josh