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: <20200703023547.qpu74obn45qvb2k7@ast-mbp.dhcp.thefacebook.com>
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?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ