[PATCH v2] use -fstack-protector-strong

Ingo Molnar mingo at kernel.org
Tue Dec 17 06:29:31 EST 2013


* Kees Cook <keescook at chromium.org> wrote:

> On Wed, Nov 27, 2013 at 10:11 AM, Kees Cook <keescook at chromium.org> wrote:
> > On Wed, Nov 27, 2013 at 9:55 AM, H. Peter Anvin <hpa at zytor.com> wrote:
> >> On 11/27/2013 09:54 AM, Ingo Molnar wrote:
> >>>>
> >>>> Looks to be 2% for defconfig. That's way better. Shall I send a v3?
> >>>
> >>> Well, it's better than 9%, but still almost an order of magnitude
> >>> higher than the cost is today, and a lot of distros have
> >>> CONFIG_CC_STACKPROTECTOR=y.
> >>>
> >>> So it would be nice to measure how much the instruction count goes up
> >>> in some realistic system-bound test. How much does something like
> >>> kernel/built-in.o increase, as per 'size' output?
> >
> >    text    data     bss     dec     hex filename
> >  929611   90851  594496 1614958  18a46e built-in.o-gcc-4.9
> >  954648   90851  594496 1639995  19063b built-in.o-gcc-4.9+strong
> >
> > Looks like 3% for defconfg + CONFIG_CC_STACKPROTECTOR
> >
> >>
> >> Do we need CONFIG_CC_STACKPROTECTOR_STRONG?
> >
> > I'm hoping to avoid this since nearly anyone using 
> > CC_STACKPROTECTOR would want strong added, but as a fallback, I'm 
> > happy to implement it as a separate config item.
> 
> Any verdict on this? Should I go with adding ..._STRONG like we used 
> to have for ..._ALL, or is defaulting to -strong best?

I'm not opposed to the feature itself, just to the specific structure 
you presented - as outlined in my review feedback.

The cost of the feature itself appears to be significant (this cost 
should be outlined in the help text btw), while I think the cost of 
adding this as a new _STRONG option is minimal.

So I'd go forward with addressing two issues:

1)

I'd add the new STACKPROTECTOR_STRONG option and maybe rename the old 
one to STACKPROTECTOR_WEAK.

If in a year or two most distros have switched over to the _STRONG 
variant, despite its costs, then we can drop the weak variant.

2)

It would also be nice to see a head to head comparison of the 3 
variants:

	!STACKPROTECTOR
	STACKPROTECTOR_LIGHT
	STACKPROTECTOR_STRONG

of defconfig vmlinux size and estimated number of checks inserted in 
each case - so people/distros can make an informed decision about the 
relative quality differences between these variants and whether they 
want to carry the costs of that.

Thanks,

	Ingo



More information about the linux-arm-kernel mailing list