[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJWsiunOLvFx5pGTXCUb+JFUQ7_HW1_+6gHSGyqraqiQqg+Aug@mail.gmail.com>
Date: Fri, 2 Mar 2018 12:09:57 -0800
From: Gianluca Borello <g.borello@...il.com>
To: Linux Networking Development Mailing List <netdev@...r.kernel.org>
Cc: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>, keescook@...omium.org
Subject: Issue accessing task_struct from BPF due to 4.16 stack-protector changes
Hello,
While testing bpf-next, I noticed that I was reading garbage when
accessing some task_struct members, and the issue seems caused by the
recent commit 2bc2f688fdf8 ("Makefile: move stack-protector
availability out of Kconfig") which removes CONFIG_CC_STACKPROTECTOR
from autoconf.h.
When I compile my BPF program, offsetof(struct task_struct, files),
which is the member I'm dereferencing, returns 1768 (where the garbage
is), whereas doing it on 4.15 returns 1776 (where the correct member
is). I believe when compiling with clang this portion of the
task_struct doesn't get considered anymore:
#ifdef CONFIG_CC_STACKPROTECTOR
/* Canary value for the -fstack-protector GCC feature: */
unsigned long stack_canary;
#endif
I solved it by adding $(KBUILD_CPPFLAGS) to my BPF Makefile (which is
pretty similar to the one used in samples/bpf/Makefile).
Two questions:
1) Do you confirm this is the proper way to handle this moving
forward? Or should there be a better way?
2) Would you consider useful a simple patch to samples/bpf/Makefile so
that other developers will not be stuck in a long bisect to figure out
why they read garbage when dereferencing task_struct? I assume that
several people use that Makefile as a template to start their project,
like I did (perhaps I'm assuming wrong though).
Thanks
Powered by blists - more mailing lists