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]

Message-ID: <20200304204506.wli3enu5w25b35h7@ast-mbp>
Date:   Wed, 4 Mar 2020 12:45:07 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Toke Høiland-Jørgensen <toke@...hat.com>,
        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 11:41:58AM -0800, Jakub Kicinski wrote:
> On Tue, 3 Mar 2020 20:36:45 -0800 Alexei Starovoitov wrote:
> > > > libxdp can choose to pin it in some libxdp specific location, so other
> > > > libxdp-enabled applications can find it in the same location, detach,
> > > > replace, modify, but random app that wants to hack an xdp prog won't
> > > > be able to mess with it.  
> > > 
> > > What if that "random app" comes first, and keeps holding on to the link
> > > fd? Then the admin essentially has to start killing processes until they
> > > find the one that has the device locked, no?  
> > 
> > Of course not. We have to provide an api to make it easy to discover
> > what process holds that link and where it's pinned.
> 
> That API to discover ownership would be useful but it's on the BPF side.

it's on bpf side because it's bpf specific.

> We have netlink notifications in networking world. The application
> which doesn't want its program replaced should simply listen to the
> netlink notifications and act if something goes wrong.

instead of locking the bike let's setup a camera and monitor the bike
when somebody steals it.
and then what? chase the thief and bring the bike back?

> > But if we go with notifier approach none of it is an issue.
> 
> Sorry, what's the notifier approach? You mean netdev notifier chain 
> or something new?

that's tbd.

> > Whether target obj is held or notifier is used everything I said before still
> > stands. "random app" that uses netlink after libdispatcher got its link FD will
> > not be able to mess with carefully orchestrated setup done by libdispatcher.
> > 
> > Also either approach will guarantee that infamous message:
> > "unregister_netdevice: waiting for %s to become free. Usage count"
> > users will never see.
> >
> > > 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?
> > 
> > > > We didn't come up with these design choices overnight. It came from
> > > > hard lessons learned while deploying xdp, tc and cgroup in production.
> > > > Legacy apis will not be deprecated, of course.  
> 
> This sounds like a version of devm_* helpers for configuration.
> Why are current user space APIs insufficient? 

current xdp, tc, cgroup apis don't have the concept of the link
and owner of that link.

> Surely all of this can 
> be done from user space.

with a camera for theft monitoring. that will work well.

> And we will need a centralized daemon for XDP
> dispatch, so why is it not a part of a daemon?

current design of libdispatcher doesn't need the deamon.