Re: [PATCH v10 03/20] x86/stackvalidate: Compile-time stack validation

Path	csiph.com!goblin2!goblin.stu.neva.ru!aioe.org!bofh.it!news.nic.it!robomod
From	Ingo Molnar <mingo@kernel.org>
Newsgroups	linux.kernel
Subject	Re: [PATCH v10 03/20] x86/stackvalidate: Compile-time stack validation
Date	Fri, 21 Aug 2015 10:00:02 +0200
Message-ID	<pZPp0-5LS-27@gated-at.bofh.it> (permalink)
References	<pXdHb-6tK-3@gated-at.bofh.it> <pXdHb-6tK-1@gated-at.bofh.it> <pXE4G-2Wa-3@gated-at.bofh.it> <pXJ4m-1DC-3@gated-at.bofh.it> <pZ8tI-2KG-5@gated-at.bofh.it> <pZpkS-1Os-9@gated-at.bofh.it>
X-Original-To	Josh Poimboeuf <jpoimboe@redhat.com>
Dkim-Signature	v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=trdQ2VIIITz1y4qy0bXfgsH+WkqeIbHkKxVy6Ub6Uyg=; b=qZygtEZh152asx3YF12IPTSnvBjzzeZsYagFQSMJ+tAM7qw9SHW1oasIvmvCqta4uo ME6aRbokzKVO60b2kXDpnHpA2MxI32G6bc2FjeHSwOfjy9emRFgmUsD/Cl90ufhMJCTU pIwF0+oty0L5gjX2BgQ5KsMyyAI5PP/JibEnLo2t7vyO80lhqlytWBZM2Z+57QO+i2uW OKzG9yd/vLt2RE5TLCpO3RwWllIKgHv+kXsQr5nT6C/Gc/1Fm9T2E0VCf5Ck9XUnAKTS vsF0/2uv448JF9/swaWDoyN/cN7H3/PSlgG0VQUfV32haYwFsngbrOQOywzG4MPWGBv0 7LWA==
X-Received	by 10.180.186.34 with SMTP id fh2mr3606369wic.94.1440143692494; Fri, 21 Aug 2015 00:54:52 -0700 (PDT)
MIME-Version	1.0
Content-Type	text/plain; charset=us-ascii
Content-Disposition	inline
User-Agent	Mutt/1.5.23 (2014-03-12)
Sender	robomod@news.nic.it
List-ID	<linux-kernel.vger.kernel.org>
X-Mailing-List	linux-kernel@vger.kernel.org
Approved	robomod@news.nic.it
Lines	53
Organization	linux.* mail to news gateway
X-Original-Cc	Andrew Morton <akpm@linux-foundation.org>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, x86@kernel.org, linux-kernel@vger.kernel.org, Michal Marek <mmarek@suse.cz>, Peter Zijlstra <peterz@infradead.org>, Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>, Linus Torvalds <torvalds@linux-foundation.org>, Andi Kleen <andi@firstfloor.org>, Pedro Alves <palves@redhat.com>, Namhyung Kim <namhyung@gmail.com>, Bernd Petrovitsch <bernd@petrovitsch.priv.at>, Chris J Arges <chris.j.arges@canonical.com>, live-patching@vger.kernel.org
X-Original-Date	Fri, 21 Aug 2015 09:54:49 +0200
X-Original-Message-ID	<20150821075449.GA10443@gmail.com>
X-Original-References	<cover.1439521412.git.jpoimboe@redhat.com> <07bf51833b5e1c52bfd9a4dbda41b80c508dffff.1439521412.git.jpoimboe@redhat.com> <20150815002354.7fb2f21e.akpm@linux-foundation.org> <20150815124913.GB3254@treble.hsd1.ky.comcast.net> <20150819100138.GA10504@gmail.com> <20150820040050.GC2944@treble.redhat.com>
X-Original-Sender	linux-kernel-owner@vger.kernel.org
Xref	csiph.com linux.kernel:1210988

Show key headers only | View raw

* Josh Poimboeuf <jpoimboe@redhat.com> wrote:

> +Why do we need stack validation?
> +--------------------------------
> +
> +Here are some of the benefits of validating stack metadata:
> +
> +a) More reliable stack traces for frame pointer enabled kernels
> +
> +   Frame pointers are used for debugging purposes.  They allow runtime
> +   code and debug tools to be able to walk the stack to determine the
> +   chain of function call sites that led to the currently executing
> +   code.
> +
> +   For some architectures, frame pointers are enabled by
> +   CONFIG_FRAME_POINTER.  For some other architectures they may be
> +   required by the ABI (sometimes referred to as "backchain pointers").
> +
> +   For C code, gcc automatically generates instructions for setting up
> +   frame pointers when the -fno-omit-frame-pointer option is used.
> +
> +   But for asm code, the frame setup instructions have to be written by
> +   hand, which most people don't do.  So the end result is that
> +   CONFIG_FRAME_POINTER is honored for C code but not for most asm code.
> +
> +   For stack traces based on frame pointers to be reliable, all
> +   functions which call other functions must first create a stack frame
> +   and update the frame pointer.  If a first function doesn't properly
> +   create a stack frame before calling a second function, the *caller*
> +   of the first function will be skipped on the stack trace.
> +
> +   The benefit of stackvalidate here is that it ensures that *all*
> +   functions honor CONFIG_FRAME_POINTER.  As a result, no functions will
> +   ever [*] be skipped on a stack trace.
> +
> +   [*] unless an interrupt or exception has occurred at the very
> +       beginning of a function before the stack frame has been created,
> +       or at the very end of the function after the stack frame has been
> +       destroyed.  This is an inherent limitation of frame pointers.

What this section does not point out is the actual effects of missing frame 
pointer annotations. I.e. how about quoting a before/after stack backtrace to 
demonstrate it?

Thanks,

	Ingo
--
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/

Thread

Re: [PATCH v10 03/20] x86/stackvalidate: Compile-time stack  validation Josh Poimboeuf <jpoimboe@redhat.com> - 2015-08-20 06:10 +0200
  Re: [PATCH v10 03/20] x86/stackvalidate: Compile-time stack  validation Ingo Molnar <mingo@kernel.org> - 2015-08-21 10:00 +0200
    Re: [PATCH v10 03/20] x86/stackvalidate: Compile-time stack  validation Josh Poimboeuf <jpoimboe@redhat.com> - 2015-08-21 15:40 +0200
      Re: [PATCH v10 03/20] x86/stackvalidate: Compile-time stack  validation Ingo Molnar <mingo@kernel.org> - 2015-08-22 11:20 +0200

csiph-web