netdev - Re: [PATCH bpf-next 0/8] tools: bpftool: add probes for system and device

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

Date:   Fri, 14 Dec 2018 11:53:54 +0000
From:   Quentin Monnet <quentin.monnet@...ronome.com>
To:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>
Cc:     netdev@...r.kernel.org, oss-drivers@...ronome.com,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Stanislav Fomichev <sdf@...gle.com>
Subject: Re: [PATCH bpf-next 0/8] tools: bpftool: add probes for system and
 device

2018-12-13 12:19 UTC+0000 ~ Quentin Monnet <quentin.monnet@...ronome.com>
> Hi,
> This set add a new command to bpftool in order to dump a list of
> eBPF-related parameters for the system (or for a specific network
> device) to the console. Once again, this is based on a suggestion from
> Daniel.
> 
> At this time, output includes:
> 

So as a reminder this one comes from an actual probe with the syscall...

>     - Availability of bpf() system call

... those 4 are read from procfs...

>     - Availability of bpf() system call for unprivileged users
>     - JIT status (enabled or not, with or without debugging traces)
>     - JIT hardening status
>     - JIT kallsyms exports status

... these are read from /boot/config-$(uname -r)...

>     - Status of kernel compilation options related to BPF features

... this from uname()...

>     - Release number of the running kernel

... and the remaining ones are probed with minimal BPF programs.

>     - Availability of known eBPF program types
>     - Availability of known eBPF map types
>     - Availability of known eBPF helper functions

As discussed with Stanislav and Daniel, some of the probing should
probably be moved to libbpf instead for the next version of this set. As
I see it, I could move probing to libbpf for:

- BPF prog and map types
- BPF helper functions
- bpf() syscall availability

I do not think kernel compile options, or kernel release number, should
go to libbpf, they're probably better in bpftool. I'm unsure about the
procfs parameters, I'm considering leaving them in bpftool for now. Do
others have an opinion about this?

Quentin