netdev - Re: [PATCH bpf-next 0/3] bpf: Populate bpffs with map and prog iterators

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: <87h7unmu7r.fsf@toke.dk>
Date:   Sat, 04 Jul 2020 12:48:40 +0200
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     torvalds@...ux-foundation.org, davem@...emloft.net,
        daniel@...earbox.net, ebiederm@...ssion.com,
        netdev@...r.kernel.org, bpf@...r.kernel.org, kernel-team@...com
Subject: Re: [PATCH bpf-next 0/3] bpf: Populate bpffs with map and prog iterators

Alexei Starovoitov <alexei.starovoitov@...il.com> writes:

> On Fri, Jul 03, 2020 at 01:18:43PM +0200, Toke HÃƒÂ¸iland-JÃƒÂ¸rgensen wrote:
>> > The user mode driver will load BPF Type Formats, create BPF maps, populate BPF
>> > maps, load two BPF programs, attach them to BPF iterators, and finally send two
>> > bpf_link IDs back to the kernel.
>> > The kernel will pin two bpf_links into newly mounted bpffs instance under
>> > names "progs" and "maps". These two files become human readable.
>> >
>> > $ cat /sys/fs/bpf/progs
>> >   id name            pages attached
>> >   11    dump_bpf_map     1 bpf_iter_bpf_map
>> >   12   dump_bpf_prog     1 bpf_iter_bpf_prog
>> >   27 test_pkt_access     1
>> >   32       test_main     1 test_pkt_access test_pkt_access
>> >   33   test_subprog1     1 test_pkt_access_subprog1 test_pkt_access
>> >   34   test_subprog2     1 test_pkt_access_subprog2 test_pkt_access
>> >   35   test_subprog3     1 test_pkt_access_subprog3 test_pkt_access
>> >   36 new_get_skb_len     1 get_skb_len test_pkt_access
>> >   37 new_get_skb_ifi     1 get_skb_ifindex test_pkt_access
>> >   38 new_get_constan     1 get_constant test_pkt_access
>> 
>> Do the iterators respect namespace boundaries? Or will I see all
>> programs/maps on the host if I cat the file inside a container?
>
> why are you asking? I'm pretty sure you know that bpf infra isn't namespaced yet.

I thought I did, but this seemed to be something that implied I was
wrong, so figured maybe I missed something.

>> > Few interesting observations:
>> > - though bpffs comes with two human readble files "progs" and "maps" they
>> >   can be removed. 'rm -f /sys/fs/bpf/progs' will remove bpf_link and kernel
>> >   will automatically unload corresponding BPF progs, maps, BTFs.
>> 
>> Is there any way to get the files back if one does this by mistake
>> (other than re-mounting the bpffs)?
>
> Same as user A pining their prog/map/link in bpffs and user B removing it.

Right, sure, but in that case A can presumably restart their application
and get it back. Whereas in this case that's not possible, short of
clearing the whole bpffs and remounting it. Would it be possible to
re-trigger the UMH on an existing fs, say by issuing 'mount -o remount
bpf /sys/fs/bpf' (or some other debug mechanism)?

-Toke