netdev - Re: [RFC PATCH bpf-next v2 00/17] bpf: implement bpf based dumping of kernel data structures

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:   Sat, 18 Apr 2020 22:30:24 -0700
From:   Yonghong Song <yhs@...com>
To:     Alan Maguire <alan.maguire@...cle.com>,
        David Ahern <dsahern@...il.com>
CC:     Andrii Nakryiko <andriin@...com>, <bpf@...r.kernel.org>,
        Martin KaFai Lau <kafai@...com>, <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>, <kernel-team@...com>
Subject: Re: [RFC PATCH bpf-next v2 00/17] bpf: implement bpf based dumping of
 kernel data structures



On 4/17/20 3:54 AM, Alan Maguire wrote:
> On Wed, 15 Apr 2020, David Ahern wrote:
> 
>> On 4/15/20 1:27 PM, Yonghong Song wrote:
>>>
>>> As there are some discussions regarding to the kernel interface/steps to
>>> create file/anonymous dumpers, I think it will be beneficial for
>>> discussion with this work in progress.
>>>
>>> Motivation:
>>>    The current way to dump kernel data structures mostly:
>>>      1. /proc system
>>>      2. various specific tools like "ss" which requires kernel support.
>>>      3. drgn
>>>    The dropback for the first two is that whenever you want to dump more, you
>>>    need change the kernel. For example, Martin wants to dump socket local
>>
>> If kernel support is needed for bpfdump of kernel data structures, you
>> are not really solving the kernel support problem. i.e., to dump
>> ipv4_route's you need to modify the relevant proc show function.
>>
> 
> I need to dig into this patchset a bit more, but if there is
> a need for in-kernel BTF-based structure dumping I've got a
> work-in-progress patchset that does this by generalizing the code
> that  deals with seq output in the verifier. I've posted it
> as an RFC in case it has anything useful to offer here:
> 
> https://lore.kernel.org/bpf/1587120160-3030-1-git-send-email-alan.maguire@oracle.com/T/#t
> 
> The idea is that by using different callback function we can achieve
> seq, snprintf or other output in-kernel using the kernel BTF data.
> I created one consumer as a proof-of-concept; it's a printk pointer
> format specifier.  Since the dump format is determined in kernel
> it's a bit constrained format-wise, but may be good enough for
> some cases.

The bpfdump work and here in-kernel btf dumping are different.
The bpfdump BPF programs are triggered with a user syscall, e.g.,
    cat /sys/kernel/bpfdump/task/my_dumper (also calling open())
or when user open() an anonymous dumper.

The BPF program can "print" some data through bpf_seq_printf()
helper. These printed data will be received by user space
through read() syscall.

Your work is greater as it makes kernel print more readable.
There is no overlap between your work and bpfdump.