All of lore.kernel.org
 help / color / mirror / Atom feed
From: mingo@kernel.org (Ingo Molnar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] use -fstack-protector-strong
Date: Tue, 26 Nov 2013 12:19:08 +0100	[thread overview]
Message-ID: <20131126111908.GB2410@gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.10.1311252310080.9667@knanqh.ubzr>


* Nicolas Pitre <nicolas.pitre@linaro.org> wrote:

> On Mon, 25 Nov 2013, Kees Cook wrote:
> 
> > On Mon, Nov 25, 2013 at 3:16 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> > > On 11/25/2013 02:14 PM, Kees Cook wrote:
> > >> Build the kernel with -fstack-protector-strong when it is available
> > >> (gcc 4.9 and later). This increases the coverage of the stack protector
> > >> without the heavy performance hit of -fstack-protector-all.
> > >
> > > What is the difference between the various options?
> > 
> > -fstack-protector-all:
> > Adds the stack-canary saving prefix and stack-canary checking suffix
> > to _all_ function entry and exit. Results in substantial use of stack
> > space for saving the canary for deep stack users (e.g. historically
> > xfs), and measurable (though shockingly still low) performance hit due
> > to all the saving/checking. Really not suitable for sane systems, and
> > was entirely removed as an option from the kernel many years ago.
> > 
> > -fstack-protector:
> > Adds the canary save/check to functions that define an 8
> > (--param=ssp-buffer-size=N, N=8 by default) or more byte local char
> > array. Traditionally, stack overflows happened with string-based
> > manipulations, so this was a way to find those functions. Very few
> > total functions actually get the canary; no measurable performance or
> > size overhead.
> > 
> > -fstack-protector-strong
> > Adds the canary for a wider set of functions, since it's not just
> > those with strings that have ultimately been vulnerable to
> > stack-busting. With this superset, more functions end up with a
> > canary, but it still remains small compared to all functions with no
> > measurable change in performance. Based on the original design
> > document, a function gets the canary when it contains any of:
> > - local variable's address used as part of the RHS of an assignment or
> > function argument
> > - local variable is an array (or union containing an array),
> > regardless of array type or length
> > - uses register local variables
> > https://docs.google.com/a/google.com/document/d/1xXBH6rRZue4f296vGt9YQcuLVQHeE516stHwt8M9xyU
> > 
> > Chrome OS has been using -fstack-protector-strong for its kernel
> > builds for the last 8 months with no problems.
> 
> Could you get this information inside the commit log for your patch 
> please?  This is very valuable info to have right next to the change 
> in the repository without having to dig into the gcc manual or 
> finding the relevant email thread.

Another piece of information we need for the changelog is a vmlinux 
kernel size comparison, with/without the patch, for a defconfig build 
(or a Ubuntu distro config build).

Thanks,

	Ingo

WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Kees Cook <keescook@chromium.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Russell King <linux@arm.linux.org.uk>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "x86@kernel.org" <x86@kernel.org>,
	Shawn Guo <shawn.guo@linaro.org>,
	Olof Johansson <olofj@chromium.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] use -fstack-protector-strong
Date: Tue, 26 Nov 2013 12:19:08 +0100	[thread overview]
Message-ID: <20131126111908.GB2410@gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.10.1311252310080.9667@knanqh.ubzr>


* Nicolas Pitre <nicolas.pitre@linaro.org> wrote:

> On Mon, 25 Nov 2013, Kees Cook wrote:
> 
> > On Mon, Nov 25, 2013 at 3:16 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> > > On 11/25/2013 02:14 PM, Kees Cook wrote:
> > >> Build the kernel with -fstack-protector-strong when it is available
> > >> (gcc 4.9 and later). This increases the coverage of the stack protector
> > >> without the heavy performance hit of -fstack-protector-all.
> > >
> > > What is the difference between the various options?
> > 
> > -fstack-protector-all:
> > Adds the stack-canary saving prefix and stack-canary checking suffix
> > to _all_ function entry and exit. Results in substantial use of stack
> > space for saving the canary for deep stack users (e.g. historically
> > xfs), and measurable (though shockingly still low) performance hit due
> > to all the saving/checking. Really not suitable for sane systems, and
> > was entirely removed as an option from the kernel many years ago.
> > 
> > -fstack-protector:
> > Adds the canary save/check to functions that define an 8
> > (--param=ssp-buffer-size=N, N=8 by default) or more byte local char
> > array. Traditionally, stack overflows happened with string-based
> > manipulations, so this was a way to find those functions. Very few
> > total functions actually get the canary; no measurable performance or
> > size overhead.
> > 
> > -fstack-protector-strong
> > Adds the canary for a wider set of functions, since it's not just
> > those with strings that have ultimately been vulnerable to
> > stack-busting. With this superset, more functions end up with a
> > canary, but it still remains small compared to all functions with no
> > measurable change in performance. Based on the original design
> > document, a function gets the canary when it contains any of:
> > - local variable's address used as part of the RHS of an assignment or
> > function argument
> > - local variable is an array (or union containing an array),
> > regardless of array type or length
> > - uses register local variables
> > https://docs.google.com/a/google.com/document/d/1xXBH6rRZue4f296vGt9YQcuLVQHeE516stHwt8M9xyU
> > 
> > Chrome OS has been using -fstack-protector-strong for its kernel
> > builds for the last 8 months with no problems.
> 
> Could you get this information inside the commit log for your patch 
> please?  This is very valuable info to have right next to the change 
> in the repository without having to dig into the gcc manual or 
> finding the relevant email thread.

Another piece of information we need for the changelog is a vmlinux 
kernel size comparison, with/without the patch, for a defconfig build 
(or a Ubuntu distro config build).

Thanks,

	Ingo

  reply	other threads:[~2013-11-26 11:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-25 22:14 [PATCH] use -fstack-protector-strong Kees Cook
2013-11-25 22:14 ` Kees Cook
2013-11-25 23:16 ` H. Peter Anvin
2013-11-25 23:16   ` H. Peter Anvin
2013-11-25 23:43   ` Kees Cook
2013-11-25 23:43     ` Kees Cook
2013-11-26  4:21     ` Nicolas Pitre
2013-11-26  4:21       ` Nicolas Pitre
2013-11-26 11:19       ` Ingo Molnar [this message]
2013-11-26 11:19         ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131126111908.GB2410@gmail.com \
    --to=mingo@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.