From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S966169AbbD1O1L (ORCPT <rfc822;w@1wt.eu>);
	Tue, 28 Apr 2015 10:27:11 -0400
Received: from bombadil.infradead.org ([198.137.202.9]:45450 "EHLO
	bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S965617AbbD1O1I (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 28 Apr 2015 10:27:08 -0400
Date: Tue, 28 Apr 2015 16:26:55 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Michal Marek <mmarek@suse.cz>,
        x86@kernel.org, live-patching@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] x86, stackvalidate: Compile-time stack frame pointer
 validation
Message-ID: <20150428142655.GG5029@twins.programming.kicks-ass.net>
References: <cover.1430142416.git.jpoimboe@redhat.com>
 <0c54981fcba75d6a32ad4074786b99bbf0fc0810.1430142416.git.jpoimboe@redhat.com>
 <20150428121606.GX23123@twins.programming.kicks-ass.net>
 <20150428140454.GA17315@treble.redhat.com>
 <20150428140842.GC23123@twins.programming.kicks-ass.net>
 <20150428142105.GB17315@treble.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150428142105.GB17315@treble.redhat.com>
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 28, 2015 at 09:21:05AM -0500, Josh Poimboeuf wrote:

> > > I tried that, but I discovered that gcc's usage of frame pointers would
> > > be a lot harder to validate.  It only sets up the frame pointer in code
> > > paths which have call instructions.  There are a lot of functions which
> > > have conditional jumps at the beginning which can jump straight to a
> > > return instruction without first doing the frame pointer setup.
> > 
> > Hmm, would not such code break your patching?
> 
> No, because we'll also do some runtime stack validation (which will be a
> future patch set).  If we detect preemption or an irq frame on the
> stack, we'll assume the stack is unreliable and delay the patching of
> the task (*).

Ah, which fixes your second issue too (the interrupt before frame
setup). OK.