From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D464C3F2D1 for ; Thu, 5 Mar 2020 18:13:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 29C1C2146E for ; Thu, 5 Mar 2020 18:13:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583432026; bh=MmGDQGgUx19Dykruo0Cq7gbv2FwEMbYDwZcR4vu6+Os=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=uCVz2SjQgYjYYIoTfpxgFdS2eWpOOs1GpWpcziRSgac3AICOSt50TovWVLWBZqhnk h7daBk9unl563d0xozQXTC0zi3+VEw48GzO1opbiScjXVLKDO1R/eHtXdPNyL6esu+ pCoCzL7cklqmLr5YzavOEabrNEGpbfPddfiulXtA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726080AbgCESNp (ORCPT ); Thu, 5 Mar 2020 13:13:45 -0500 Received: from mail.kernel.org ([198.145.29.99]:38682 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726036AbgCESNp (ORCPT ); Thu, 5 Mar 2020 13:13:45 -0500 Received: from kicinski-fedora-PC1C0HJN (unknown [163.114.132.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 72AD3208C3; Thu, 5 Mar 2020 18:13:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583432024; bh=MmGDQGgUx19Dykruo0Cq7gbv2FwEMbYDwZcR4vu6+Os=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Vz1BUssI0NEhzosLWpEr+RiciXDS6RcTrXWqtOuq2RPYzTY5rymONNq9lI4RGNtQM qto0N2RD1cqfHfq11AylBRGbbdSC8LYtVCbmTlkuFXiujZ0jWnnYeyEM65z0ndIGxM DzNHwvojzKghXagVnyIxRSnc0IgUCPnxWI6rUcBA= Date: Thu, 5 Mar 2020 10:13:42 -0800 From: Jakub Kicinski To: Toke =?UTF-8?B?SMO4aWxhbmQtSsO4cmdlbnNlbg==?= Cc: Alexei Starovoitov , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Andrii Nakryiko , bpf , Networking , Kernel Team Subject: Re: [PATCH bpf-next 0/3] Introduce pinnable bpf_link kernel abstraction Message-ID: <20200305101342.01427a2a@kicinski-fedora-PC1C0HJN> In-Reply-To: <87tv332hak.fsf@toke.dk> References: <8083c916-ac2c-8ce0-2286-4ea40578c47f@iogearbox.net> <87pndt4268.fsf@toke.dk> <87k1413whq.fsf@toke.dk> <20200304043643.nqd2kzvabkrzlolh@ast-mbp> <20200304114000.56888dac@kicinski-fedora-PC1C0HJN> <20200304204506.wli3enu5w25b35h7@ast-mbp> <20200304132439.6abadbe3@kicinski-fedora-PC1C0HJN> <20200305010706.dk7zedpyj5pb5jcv@ast-mbp> <20200305001620.204c292e@cakuba.hsd1.ca.comcast.net> <87tv332hak.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, 05 Mar 2020 12:05:23 +0100 Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Jakub Kicinski writes: > > On Wed, 4 Mar 2020 17:07:08 -0800, Alexei Starovoitov wrote: =20 > >> > Maybe also the thief should not have CAP_ADMIN in the first place? > >> > And ask a daemon to perform its actions.. =20 > >>=20 > >> a daemon idea keeps coming back in circles. > >> With FD-based kprobe/uprobe/tracepoint/fexit/fentry that problem is go= ne, > >> but xdp, tc, cgroup still don't have the owner concept. > >> Some people argued that these three need three separate daemons. > >> Especially since cgroups are mainly managed by systemd plus container > >> manager it's quite different from networking (xdp, tc) where something > >> like 'networkd' might makes sense. > >> But if you take this line of thought all the ways systemd should be th= at > >> single daemon to coordinate attaching to xdp, tc, cgroup because > >> in many cases cgroup and tc progs have to coordinate the work. =20 > > > > The feature creep could happen, but Toke's proposal has a fairly simple > > feature set, which should be easy to cover by a stand alone daemon. > > > > Toke, I saw that in the library discussion there was no mention of=20 > > a daemon, what makes a daemon solution unsuitable? =20 >=20 > Quoting from the last discussion[0]: >=20 > > - Introducing a new, separate code base that we'll have to write, suppo= rt > > and manage updates to. > > > > - Add a new dependency to using XDP (now you not only need the kernel > > and libraries, you'll also need the daemon). > > > > - Have to duplicate or wrap functionality currently found in the kernel; > > at least: > > =20 > > - Keeping track of which XDP programs are loaded and attached to > > each interface (as well as the "new state" of their attachment > > order). > > > > - Some kind of interface with the verifier; if an app does > > xdpd_rpc_load(prog), how is the verifier result going to get back > > to the caller? > > > > - Have to deal with state synchronisation issues (how does xdpd handle > > kernel state changing from underneath it?). > >=20 > > While these are issues that are (probably) all solvable, I think the > > cost of solving them is far higher than putting the support into the > > kernel. Which is why I think kernel support is the best solution :) =20 >=20 > The context was slightly different, since this was before we had > freplace support in the kernel. But apart from the point about the > verifier, I think the arguments still stand. In fact, now that we have > that, we don't even need userspace linking, so basically a daemon's only > task would be to arbitrate access to the XDP hook? In my book, > arbitrating access to resources is what the kernel is all about... You said that like the library doesn't arbitrate access and manage resources.. It does exactly the same work the daemon would do. Your prog chaining in the kernel proposal, now that would be a kernel mechanism, but that's not what we're discussing here. Daemon just trades off the complexity of making calls for the complexity of the system and serializing/de-serializing the state.