netdev - Re: [PATCH bpf-next 3/3] bpf: Add kernel module with user mode driver that populates bpffs.

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:   Thu, 2 Jul 2020 19:35:47 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     David Miller <davem@...emloft.net>,
        Daniel Borkmann <daniel@...earbox.net>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Netdev <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        kernel-team@...com
Subject: Re: [PATCH bpf-next 3/3] bpf: Add kernel module with user mode
 driver that populates bpffs.

On Thu, Jul 02, 2020 at 06:05:29PM -0700, Linus Torvalds wrote:
> On Thu, Jul 2, 2020 at 1:03 PM Alexei Starovoitov
> <alexei.starovoitov@...il.com> wrote:
> >
> > The BPF program dump_bpf_prog() in iterators.bpf.c is printing this data about
> > all BPF programs currently loaded in the system. This information is unstable
> > and will change from kernel to kernel.
> 
> If so, it should probably be in debugfs, not in /sys/fs/

/sys/fs/bpf/ is just a historic location where we chose to mount bpffs.
iirc iproute2 picked that location and systemd followed.
bpffs itself is not a single mount and not sharing anything with sysfs or debugfs.
By default it's not mounted anywhere.
Every instance is independent and can contain only pinned BPF objects:
progs, maps, links.
Folks are using bpffs to store BPF objects that need to survive the life time
of the process that created those objects.
Another use is to share that BPF object with another process.
Like firewall service can load bpf prog attach to netdev and pin bpf map
with firewall rules in some /var/my_firewall/bpf/my_fw_rules.
Then another process can do map lookup/delete on that map if it can access the path.
I've seen such use case in production.
As far as preloading "progs" and "maps" iterators into bpffs the following
works just as well:
$ mkdir /aa
$ mount bpffs /aa -t bpf
$ ll /aa
total 4
drwxrwxrwt  2 root root    0 Jul  2 00:27 .
drwxr-xr-x 19 root root 4096 Jul  2 00:09 ..
-rw-------  1 root root    0 Jul  2 00:27 maps
-rw-------  1 root root    0 Jul  2 00:27 progs
$ cat /aa/progs
  id name            pages attached
  17    dump_bpf_map     1 bpf_iter_bpf_map
  18   dump_bpf_prog     1 bpf_iter_bpf_prog

May be I misunderstood what you meant?