linux-kernel - Re: [PATCH bpf-next 0/6] bpftool: Allow to select sections and filter probes

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:   Tue, 18 Feb 2020 19:02:49 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Michal Rostecki <mrostecki@...nsuse.org>
Cc:     bpf <bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andriin@...com>,
        Quentin Monnet <quentin.monnet@...ronome.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Network Development <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Shuah Khan <shuah@...nel.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH bpf-next 0/6] bpftool: Allow to select sections and filter probes

On Tue, Feb 18, 2020 at 11:02 AM Michal Rostecki <mrostecki@...nsuse.org> wrote:
>
> This patch series extend the "bpftool feature" subcommand with the
> new positional arguments:
>
> - "section", which allows to select a specific section of probes (i.e.
>   "system_config", "program_types", "map_types");
> - "filter_in", which allows to select only probes which matches the
>   given regex pattern;
> - "filter_out", which allows to filter out probes which do not match the
>   given regex pattern.
>
> The main motivation behind those changes is ability the fact that some
> probes (for example those related to "trace" or "write_user" helpers)
> emit dmesg messages which might be confusing for people who are running
> on production environments. For details see the Cilium issue[0].
>
> [0] https://github.com/cilium/cilium/issues/10048

The motivation is clear, but I think the users shouldn't be made
aware of such implementation details. I think instead of filter_in/out
it's better to do 'full or safe' mode of probing.
By default it can do all the probing that doesn't cause
extra dmesgs and in 'full' mode it can probe everything.