lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ