Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753499AbbGNVai (ORCPT ); Tue, 14 Jul 2015 17:30:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42347 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753319AbbGNVah (ORCPT ); Tue, 14 Jul 2015 17:30:37 -0400 Date: Tue, 14 Jul 2015 16:30:34 -0500 From: Josh Poimboeuf To: Peter Zijlstra 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, Steven Rostedt Subject: Re: [PATCH v7 2/4] x86/stackvalidate: Compile-time stack validation Message-ID: <20150714213034.GB13950@treble.redhat.com> References: <20150714210858.GP19282@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150714210858.GP19282@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3378 Lines: 75 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/