On Fri, Mar 2, 2018 at 2:26 PM, Alexei Starovoitov
<alexei.starovoi...@gmail.com> wrote:
> On Fri, Mar 02, 2018 at 02:04:17PM -0800, Gianluca Borello wrote:
>> On Fri, Mar 2, 2018 at 12:42 PM, Alexei Starovoitov
>> <alexei.starovoi...@gmail.com> wrote:
>> >
>> > good catch!
>> > I wonder why sched.h is using this flag insead of relying on #defines from 
>> > autoconf.h
>> > It could have been using CONFIG_HAVE_CC_STACKPROTECTOR
>> > instead of CONFIG_CC_STACKPROTECTOR, no ?
>> >
>> Thanks for your reply Alexei. I think switching to
>> HAVE_CC_STACKPROTECTOR could indeed solve this particular BPF issue in
>> a cleaner way (I tested it), at the cost of having that struct member
>> always present for the supported architectures even if the stack
>> protector is actually disabled (e.g. CONFIG_CC_STACKPROTECTOR_NONE=y).

CONFIG_CC_STACKPROTECTOR_AUTO may result in no stack protector, so
CONFIG_CC_STACKPROTECTOR is the way to determine if it should exist.

> let's fix it properly instead of adding more hacks to Makefiles

It is being fixed properly -- the detection code is being moved out of
Makefile into Kconfig, at which point this won't be as weird as it is.

If KBUILD_CPPFLAGS won't work for you, I'm not hugely opposed to
switching the task_struct ifdef to HAVE_CC_STACKPROTECTOR, since it is
extremely rare to build without stack protector on architectures that
support it.


Kees Cook
Pixel Security

Reply via email to