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). > > if defined(HAVE_CC_STACKPROTECTOR) && !defined(CONFIG_CC_STACKPROTECTOR_NONE)
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 -- Kees Cook Pixel Security
