netdev - Re: [PATCH bpf-next 0/3] Introduce pinnable bpf

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:   Wed, 4 Mar 2020 07:47:59 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH bpf-next 0/3] Introduce pinnable bpf_link kernel
 abstraction

On Wed, Mar 04, 2020 at 08:47:44AM +0100, Toke Høiland-Jørgensen wrote:
> >
> >> And what about the case where the link fd is pinned on a bpffs that is
> >> no longer available? I.e., if a netdevice with an XDP program moves
> >> namespaces and no longer has access to the original bpffs, that XDP
> >> program would essentially become immutable?
> >
> > 'immutable' will not be possible.
> > I'm not clear to me how bpffs is going to disappear. What do you mean
> > exactly?
> 
> # stat /sys/fs/bpf | grep Device
> Device: 1fh/31d	Inode: 1013963     Links: 2
> # mkdir /sys/fs/bpf/test; ls /sys/fs/bpf
> test
> # ip netns add test
> # ip netns exec test stat /sys/fs/bpf/test
> stat: cannot stat '/sys/fs/bpf/test': No such file or directory
> # ip netns exec test stat /sys/fs/bpf | grep Device
> Device: 3fh/63d	Inode: 12242       Links: 2
> 
> It's a different bpffs instance inside the netns, so it won't have
> access to anything pinned in the outer one...

Toke, please get your facts straight.

> # stat /sys/fs/bpf | grep Device
> Device: 1fh/31d	Inode: 1013963     Links: 2

Inode != 1 means that this is not bpffs.
I guess this is still sysfs.

> # mkdir /sys/fs/bpf/test; ls /sys/fs/bpf
> test
> # ip netns add test
> # ip netns exec test stat /sys/fs/bpf/test
> stat: cannot stat '/sys/fs/bpf/test': No such file or directory
> # ip netns exec test stat /sys/fs/bpf | grep Device
> Device: 3fh/63d	Inode: 12242       Links: 2

This is your new sysfs after ip netns exec.

netns has nothing do with bpffs despite your claims.

Try this instead:
# mkdir /tmp/bpf
# mount -t bpf bpf /tmp/bpf
# stat /tmp/bpf|grep Device
Device: 1eh/30d	Inode: 1           Links: 2
# stat -f /tmp/bpf|grep Type
    ID: 0        Namelen: 255     Type: bpf_fs
# mkdir /tmp/bpf/test
# ip netns add my
# ip netns exec my stat /tmp/bpf|grep Device
Device: 1eh/30d	Inode: 1           Links: 3
# ip netns exec my stat -f /tmp/bpf|grep Type
    ID: 0        Namelen: 255     Type: bpf_fs
# ip netns exec my ls /tmp/bpf/
test

Having said that we do allow remounting bpffs on top of existing one:
# mount -t bpf bpf /var/aa
# mkdir /var/aa/bb
# stat -f /var/aa/bb|grep Type
    ID: 0        Namelen: 255     Type: bpf_fs
# mount -t bpf bpf /var/aa
# stat -f /var/aa/bb|grep Type
stat: cannot read file system information for '/var/aa/bb': No such file or directory
# umount /var/aa
# stat -f /var/aa/bb|grep Type
    ID: 0        Namelen: 255     Type: bpf_fs

Still that doesn't mean that pinned link is 'immutable'.