netdev - Re: [PATCH bpf] tools: bpftool: fix compilation with older headers

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2b69d396-2357-e424-b70d-bf940cf916e1@iogearbox.net>
Date:   Tue, 6 Mar 2018 17:28:33 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     David Miller <davem@...emloft.net>, jbenc@...hat.com
Cc:     netdev@...r.kernel.org, ast@...nel.org,
        jakub.kicinski@...ronome.com, acme@...hat.com
Subject: Re: [PATCH bpf] tools: bpftool: fix compilation with older headers

[ +acme ]

On 03/06/2018 05:00 PM, David Miller wrote:
> From: Jiri Benc <jbenc@...hat.com>
> Date: Tue, 6 Mar 2018 16:03:25 +0100
> 
>> On Tue, 6 Mar 2018 15:39:07 +0100, Daniel Borkmann wrote:
>>> Thanks for the fix, Jiri! The standard approach to resolve such header dependencies under
>>> tools/ would be to add a copy of magic.h uapi header into tools/include/uapi/linux/magic.h.
>>>
>>> Both bpftool and libbpf have tools/include/uapi/ in their include path from their
>>> Makefile, so they would pull this in automatically and it would also allow to get rid
>>> of the extra ifdef in libbpf then. Could you look into that?
>>
>> That's what I tried at first. But honestly, this is a shortcut to hell.
>> Eventually, we'd end up with most of uapi headers duplicated under
>> tools/include/uapi and hopelessly out of sync.
>>
>> The right approach would be to export uapi headers from the currently
>> built kernel somewhere (a temporary directory, perhaps) and use that to
>> build the tools. We should not have duplicated and out of sync headers
>> in the kernel tree. Just look at the git log for tools/include/uapi to
>> see what I mean by "out of sync".
> 
> I understand your frustration.
> 
> I'm really puzzled why doing "make headers_install" and then building
> these tools does not pick those in-kernel headers up.  That's what
> really should happen.

Arnaldo, given this came out of tools/perf originally and duplicating/syncing
headers is common practice since about 2014 in kernel git tree, do you have
some context on why the above was/is not considered?

My current understanding is that the general preference would be on copying
the headers into tools/include/ infrastructure once there are dependencies
identified that would be missing on older/local system headers rather than
ifdef'ery of various bit and pieces in the code that need to make use of them.
Would be good to get some clarification on that in any case.

But that said, I'd also be fine taking the three-liner as is into bpf as a fix.

> The kernel tree internally should be self-consistent.
> 
> It's one thing for an external tool like iproute2 to duplicate stuff
> like this, but user programs inside the kernel have no excuse for
> requiring things like that just to build.