Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161080AbbEVWW4 (ORCPT ); Fri, 22 May 2015 18:22:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36945 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161013AbbEVWWz (ORCPT ); Fri, 22 May 2015 18:22:55 -0400 Date: Fri, 22 May 2015 17:22:51 -0500 From: Josh Poimboeuf To: Jiri Kosina Cc: Borislav Petkov , Ingo Molnar , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Michal Marek , Peter Zijlstra , x86@kernel.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Linus Torvalds , Andy Lutomirski , Denys Vlasenko , Brian Gerst , Peter Zijlstra , Andrew Morton Subject: Re: [PATCH v4 0/3] Compile-time stack frame pointer validation Message-ID: <20150522222251.GE20555@treble.redhat.com> References: <20150520103339.GA22205@gmail.com> <20150520141331.GA16995@treble.redhat.com> <20150520144810.GA10374@gmail.com> <20150521205425.GA31662@treble.redhat.com> <20150521220158.GH3689@pd.tnic> <20150522143212.GB20555@treble.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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: 1241 Lines: 30 On Fri, May 22, 2015 at 11:18:57PM +0200, Jiri Kosina wrote: > On Fri, 22 May 2015, Josh Poimboeuf wrote: > > > Hm, alternatives do complicate things a bit. It *is* a false positive, > > but not necessarily because its part of an alternative instruction > > block. > > > > The above code would be patched into memmove(), which is a leaf function > > because it doesn't call any other functions. Leaf functions don't need > > frame pointer logic, so we can ignore them. > > > > If instead the above code were patched into a non-leaf function, we'd > > have to change it to restore the frame pointer before returning. > > Is this really only a problem of alternatives? How about > dynamically-enabled tracepoints? I think tracepoints are only in C code, right? stackvalidate only analyzes asm code, so it's not a concern for this patch set. And I think tracepoints rely on normal call instructions, so they shouldn't cause any problems with frame pointers as far as I can tell. -- 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/