Messages in this thread | | | Date | Wed, 13 Jan 2021 20:23:15 +0000 | From | Mark Brown <> | Subject | Re: [PATCH] Documentation: livepatch: document reliable stacktrace |
| |
On Wed, Jan 13, 2021 at 01:33:13PM -0600, Josh Poimboeuf wrote:
> 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.
> 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?
> > +There are several ways an architecture may identify kernel code which is deemed > > +unreliable to unwind from, e.g.
> > +* Using metadata created by objtool, with such code annotated with > > + SYM_CODE_{START,END} or STACKFRAME_NON_STANDARD().
> 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. [unhandled content-type:application/pgp-signature] | |