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: <20180306.110050.853264455892964392.davem@davemloft.net>
Date:   Tue, 06 Mar 2018 11:00:50 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     jbenc@...hat.com
Cc:     daniel@...earbox.net, netdev@...r.kernel.org, ast@...nel.org,
        jakub.kicinski@...ronome.com
Subject: Re: [PATCH bpf] tools: bpftool: fix compilation with older headers

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.

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.