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

Date:   Wed, 19 Feb 2020 21:57:00 +0100
From:   Michal Rostecki <mrostecki@...nsuse.org>
To:     Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     bpf <bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andriin@...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 2/19/20 5:52 PM, Daniel Borkmann wrote:
> On 2/19/20 5:37 PM, Alexei Starovoitov wrote:
>> On Wed, Feb 19, 2020 at 4:33 AM Michal Rostecki
>> <mrostecki@...nsuse.org> wrote:
>>>
>>> On 2/19/20 4:02 AM, Alexei Starovoitov wrote:
>>>> 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.
>>>
>>> Alright, then I will send later v2 where the "internal" implementation
>>> (filtering out based on regex) stays similar (filter_out will stay in
>>> the code without being exposed to users, filter_in will be removed). And
>>> the exposed option of "safe" probing will just apply the
>>> "(trace|write_user)" filter_out pattern. Does it sound good?
>>
>> yes. If implementation is doing filter_in and applying
>> 'trace_printk|write_user'
>> strings hidden within bpftool than I think it should be good.
>> What do you think the default should be?
>> It feels to me that the default should not be causing dmesg prints.
>> So only addition flag for bpftool command line will be 'bpftool
>> feature probe full'
> 
> Agree, that makes sense to me.

Makes sense to me as well. I will do that in v2.