netdev - Re: [oss-drivers] 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]

Message-ID: <656b0d7e-6317-5446-b90f-79d97b78641d@netronome.com>
Date:   Fri, 14 Dec 2018 18:41:29 +0000
From:   Quentin Monnet <quentin.monnet@...ronome.com>
To:     Stanislav Fomichev <sdf@...ichev.me>
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: [oss-drivers] Re: [PATCH bpf-next 0/8] tools: bpftool: add probes
 for system and device

2018-12-14 10:21 UTC-0800 ~ Stanislav Fomichev <sdf@...ichev.me>
> 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)?

Agree with it, I'll work on a new version for next week. Thanks!