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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 14 Dec 2018 10:21:12 -0800
From:   Stanislav Fomichev <sdf@...ichev.me>
To:     Quentin Monnet <quentin.monnet@...ronome.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>, 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

On 12/14, Quentin Monnet wrote:
> 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
+1
Kernel + /proc stuff can probably live in bpftool.

> procfs parameters, I'm considering leaving them in bpftool for now. Do
> others have an opinion about this?
Maybe start with adding prog/map/helpers probes to the libbpf
(+ifindex)?

> 
> Quentin