netdev - Re: [RFC PATCH bpf-next 03/16] bpf: provide a way for targets to register themselves

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: <CAEf4BzYd5gkytGookaVU_nCVVyxTYM1Z4ohqPFZW2YSY2VJ9Fg@mail.gmail.com>
Date:   Fri, 10 Apr 2020 15:25:16 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Yonghong Song <yhs@...com>
Cc:     Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
        Martin KaFai Lau <kafai@...com>,
        Networking <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <kernel-team@...com>
Subject: Re: [RFC PATCH bpf-next 03/16] bpf: provide a way for targets to
 register themselves

On Wed, Apr 8, 2020 at 4:26 PM Yonghong Song <yhs@...com> wrote:
>
> Here, the target refers to a particular data structure
> inside the kernel we want to dump. For example, it
> can be all task_structs in the current pid namespace,
> or it could be all open files for all task_structs
> in the current pid namespace.
>
> Each target is identified with the following information:
>    target_rel_path   <=== relative path to /sys/kernel/bpfdump
>    target_proto      <=== kernel func proto which represents
>                           bpf program signature for this target
>    seq_ops           <=== seq_ops for seq_file operations
>    seq_priv_size     <=== seq_file private data size
>    target_feature    <=== target specific feature which needs
>                           handling outside seq_ops.
>
> The target relative path is a relative directory to /sys/kernel/bpfdump/.
> For example, it could be:
>    task                  <=== all tasks
>    task/file             <=== all open files under all tasks
>    ipv6_route            <=== all ipv6_routes
>    tcp6/sk_local_storage <=== all tcp6 socket local storages
>    foo/bar/tar           <=== all tar's in bar in foo
>
> The "target_feature" is mostly used for reusing existing seq_ops.
> For example, for /proc/net/<> stats, the "net" namespace is often
> stored in file private data. The target_feature enables bpf based
> dumper to set "net" properly for itself before calling shared
> seq_ops.
>
> bpf_dump_reg_target() is implemented so targets
> can register themselves. Currently, module is not
> supported, so there is no bpf_dump_unreg_target().
> The main reason is that BTF is not available for modules
> yet.
>
> Since target might call bpf_dump_reg_target() before
> bpfdump mount point is created, __bpfdump_init()
> may be called in bpf_dump_reg_target() as well.
>
> The file-based dumpers will be regular files under
> the specific target directory. For example,
>    task/my1      <=== dumper "my1" iterates through all tasks
>    task/file/my2 <=== dumper "my2" iterates through all open files
>                       under all tasks
>
> Signed-off-by: Yonghong Song <yhs@...com>
> ---
>  include/linux/bpf.h |   4 +
>  kernel/bpf/dump.c   | 190 +++++++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 193 insertions(+), 1 deletion(-)
>

[...]

> +
> +static int dumper_unlink(struct inode *dir, struct dentry *dentry)
> +{
> +       kfree(d_inode(dentry)->i_private);
> +       return simple_unlink(dir, dentry);
> +}
> +
> +static const struct inode_operations bpf_dir_iops = {

noticed this reading next patch. It should probably be called
bpfdump_dir_iops to avoid confusion with bpf_dir_iops of BPF FS in
kernel/bpf/inode.c?

> +       .lookup         = simple_lookup,
> +       .unlink         = dumper_unlink,
> +};
> +

[...]