netdev - Re: [PATCH bpf v3] x86/cpufeature: bpf hack for clang not supporting asm goto

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: <CAJWsiu=6gNzepWSvySZvmLsRckLE0kpYEFAave0HUJdDSjf9FQ@mail.gmail.com>
Date:   Thu, 10 May 2018 17:57:43 +0000
From:   Gianluca Borello <g.borello@...il.com>
To:     bp@...en8.de
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        peterz@...radead.org, Yonghong Song <yhs@...com>, mingo@...nel.org,
        torvalds@...ux-foundation.org, Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        Linux Networking Development Mailing List 
        <netdev@...r.kernel.org>, kernel-team@...com, tglx@...utronix.de
Subject: Re: [PATCH bpf v3] x86/cpufeature: bpf hack for clang not supporting
 asm goto

On Thu, May 10, 2018 at 9:28 AM Borislav Petkov <bp@...en8.de> wrote:

> As someone already pointed out on IRC, arch/x86/include/asm/cpufeature.h
> is solely a kernel header so nothing but kernel should include it. So
> forget the userspace breakage "argument".

For what is worth, I have the same exact problem in a relatively popular
open source system call tracer, and my attempt to fix the issue from user
space has been:
https://github.com/draios/sysdig/commit/2958eb1d52e047f4b93d1238be803e7c405bdec2

While I can definitely live with that (and I'd be happy to submit a patch
to samples/ following the same approach) and absolutely respect the
technical authority of the reviewers here, it would be nice to recognize
that these changes actually affect users to a certain degree, even if from
a technical point of view they don't break userspace.

 From a practical point of view, BPF is widely used from userspace programs
to access some kernel data structures to gather visibility information, and
even the simplest use case, such as including linux/sched.h to access some
task_struct members, ends up pulling in arch/x86/include/asm/cpufeature.h,
thus (ab)using that file. Adding these quirks definitely increases the
complexity a developer needs to keep in mind in order to take advantage of
a BPF based instrumentation.

Thanks