linux-kernel - Re: Fwd: struct pt_regs missing in /usr/include/ tree for eBPF program compile

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20170823050109.vyubf33dru2fdd3w@ast-mbp>
Date:   Tue, 22 Aug 2017 22:01:11 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Heiko Carstens <heiko.carstens@...ibm.com>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        Thomas-Mich Richter <tmricht@...ux.vnet.ibm.com>,
        ast@...nel.org, Hendrik Brueckner <brueckner@...ux.vnet.ibm.com>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        linux-kernel@...r.kernel.org,
        Michael Holzheu <holzheu@...ux.vnet.ibm.com>,
        davem@...emloft.net, yhs@...com, linux-arch@...r.kernel.org,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: Fwd: struct pt_regs missing in /usr/include/ tree for eBPF
 program compile

On Mon, Aug 14, 2017 at 02:08:07PM +0200, Heiko Carstens wrote:
> > Now, I would like to avoid going down that road to pull
> > in kernel internal headers into test_verifier.c, could
> > we instead add a bpf_ptregs.h helper in tools/testing/selftests/bpf/,
> > where s390 and arm64 would put a definition to fallback when
> > otherwise not available? Admittedly, it's a bit of a hack
> > if exporting them is not an option, but 'normal' tracing
> > progs would consult kernel headers anyway. Thoughts?
>
> I really don't think that struct pt_regs is part of uapi and should be
> exported. We did change the layout of the pt_regs structure more than once
> and would like to be able to do so in the future as well.

I think Daniel's suggestion above it the best solution and doesn't
prevent future modification to pt_regs on s390.

> We could add the hack you outlined above, but I'd like to have the same API
> for all architectures. Otherwise we keep adding special cases for
> architectures which don't export pt_regs via uapi (which I think is wrong).

I don't see any other choice but to make this hack for s390/arm64
The programs need to be able to access the registers in the format that
kernel keeps, since the programs are attached to kprobe and perf_events
and are walking in-kernel data structures.
It's already well understood that kprobe+bpf is unstable api, so having
pt_regs being unstable on s390/arm64 doesn't make it any worse.