Date:	Tue, 14 Jul 2015 16:30:34 -0500
From:	Josh Poimboeuf <jpoimboe@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Michal Marek <mmarek@...e.cz>,
	Andy Lutomirski <luto@...nel.org>,
	Borislav Petkov <bp@...en8.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>,
	Pedro Alves <palves@...hat.com>, x86@...nel.org,
	live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH v7 2/4] x86/stackvalidate: Compile-time stack validation

On Tue, Jul 14, 2015 at 11:08:58PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 14, 2015 at 12:14:08PM -0500, Josh Poimboeuf wrote:
> > This adds a CONFIG_STACK_VALIDATION option which enables a host tool
> > named stackvalidate which runs at compile time.  It 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.
> > 
> > Currently it checks frame pointer usage.  I plan to add DWARF CFI
> > validation as well.
> > 
> > For each function, it recursively follows all possible code paths and
> > validates the correct frame pointer state at each instruction.
> > 
> > It also follows code paths involving special sections, like
> > .altinstructions, __jump_table, and __ex_table, which can add
> > 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.
> > 
> > To achieve the validation, stackvalidate enforces the following rules:
> > 
> > 1. Each callable function must be annotated as such with the ELF
> >    function type.  In asm code, this is typically done using the
> >    ENTRY/ENDPROC macros.  If stackvalidate finds a return instruction
> >    outside of a function, it flags an error since that usually indicates
> >    callable code which should be annotated accordingly.
> > 
> > 2. Conversely, each section of code which is *not* callable should *not*
> >    be annotated as an ELF function.  The ENDPROC macro shouldn't be used
> >    in this case.
> > 
> > 3. Each callable function which calls another function must have the
> >    correct frame pointer logic, if required by CONFIG_FRAME_POINTER or
> >    the architecture's back chain rules.  This can by done in asm code
> >    with the FRAME/ENDFRAME macros.
> > 
> > 4. Dynamic jumps and jumps to undefined symbols are only allowed if:
> > 
> >    a) the jump is part of a switch statement; or
> > 
> >    b) the jump matches sibling call semantics and the frame pointer has
> >       the same value it had on function entry.
> > 
> > 5. A callable function may not execute kernel entry/exit instructions.
> >    The only code which needs such instructions is kernel entry code,
> >    which shouldn't be in callable functions anyway.
> 
> 
> How (if it does at all) deal with function-trace / -pg -fprofile-arcs
> things? Does it silently ignore the __mcount calls and assumes ftrace
> knows wtf its doing? ;-)

Adding Steven to CC to keep me honest.

In the case of "-pg -mfentry", which is what ftrace has relied on for
the past few years for newer versions of gcc, stackvalidate silently
ignores __fentry__ calls and assumes that ftrace indeed knows wtf it's
doing.  I don't see a problem there as long as the ftrace handler
doesn't sleep.

I haven't run stackvalidate on the old "-pg" mcount non-fentry stuff,
but I think it creates a stack frame before calling mcount, so it should
be fine.

I don't know much about -fprofile-arcs, but as far as I can tell, it's
only used for gcov.

-- 
Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists