[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20131218095905.GB19319@gmail.com>
Date: Wed, 18 Dec 2013 10:59:05 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Kees Cook <keescook@...omium.org>
Cc: linux-kernel@...r.kernel.org, Michal Marek <mmarek@...e.cz>,
Russell King <linux@....linux.org.uk>,
Ralf Baechle <ralf@...ux-mips.org>,
Paul Mundt <lethal@...ux-sh.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
James Hogan <james.hogan@...tec.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Shawn Guo <shawn.guo@...aro.org>, x86@...nel.org,
linux-kbuild@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-mips@...ux-mips.org, linux-sh@...r.kernel.org
Subject: Re: [PATCH v3 2/2] provide -fstack-protector-strong build option
* Kees Cook <keescook@...omium.org> wrote:
> This changes the stack protector config option into a choice of "None",
> "Regular", and "Strong". For "Strong", the kernel is built with
> -fstack-protector-strong (gcc 4.9 and later). This options increases
> the coverage of the stack protector without the heavy performance hit
> of -fstack-protector-all.
>
> For reference, the stack protector options available in gcc are:
>
> -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
>
> Comparison of "size" output when built with gcc-4.9 in three configurations:
> - defconfig
> - defconfig + CONFIG_CC_STACKPROTECTOR (+0.33%)
> - defconfig + CONFIG_CC_STACKPROTECTOR_STRONG via this patch (+2.24%)
>
> text data bss dec hex filename
> 11430641 1457584 1191936 14080161 d6d8a1 vmlinux
> 11468490 1457584 1191936 14118010 d76c7a vmlinux.stackprotector
> 11692790 1457584 1191936 14342310 dad8a6 vmlinux.stackprotector-strong
Beyond the kernel size calculation, could you please also provide an
estimation about the _number_ of functions affected, out of N kernel
functions, so that the user has a rough picture about the scope and
distribution of these variants?
I.e. something like:
# of canary checks
..................................................................................
- defconfig 0 functions out of 100k functions
- defconfig + STACKPROTECTOR 1k functions out of 100k functions
- defconfig + STACKPROTECTOR_STRONG 20k functions out of 100k functions
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists