Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753559AbbGNVJI (ORCPT ); Tue, 14 Jul 2015 17:09:08 -0400 Received: from casper.infradead.org ([85.118.1.10]:33579 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753497AbbGNVJG (ORCPT ); Tue, 14 Jul 2015 17:09:06 -0400 Date: Tue, 14 Jul 2015 23:08:58 +0200 From: Peter Zijlstra To: Josh Poimboeuf Cc: Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Michal Marek , Andy Lutomirski , Borislav Petkov , Linus Torvalds , Andi Kleen , Pedro Alves , x86@kernel.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v7 2/4] x86/stackvalidate: Compile-time stack validation Message-ID: <20150714210858.GP19282@twins.programming.kicks-ass.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2625 Lines: 56 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/