linux-kernel - Re: [PATCH v7 2/4] x86/stackvalidate: Compile-time stack validation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 14 Jul 2015 23:08:58 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Josh Poimboeuf <jpoimboe@...hat.com>
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
Subject: Re: [PATCH v7 2/4] x86/stackvalidate: Compile-time stack validation

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? ;-)
--
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/