* Kees Cook <[email protected]> wrote:
> On Wed, Nov 27, 2013 at 10:11 AM, Kees Cook <[email protected]> wrote:
> > On Wed, Nov 27, 2013 at 9:55 AM, H. Peter Anvin <[email protected]> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
