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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 25560C2D0E9 for ; Thu, 26 Mar 2020 19:59:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F317B206E6 for ; Thu, 26 Mar 2020 19:59:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rqCWmZWE" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728692AbgCZT7E (ORCPT ); Thu, 26 Mar 2020 15:59:04 -0400 Received: from mail-pj1-f65.google.com ([209.85.216.65]:51980 "EHLO mail-pj1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727851AbgCZT7E (ORCPT ); Thu, 26 Mar 2020 15:59:04 -0400 Received: by mail-pj1-f65.google.com with SMTP id w9so2930264pjh.1; Thu, 26 Mar 2020 12:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=t65dqCPU1l76vOHm7W6FbHIpgdz9VRI/oHeiqigs5q0=; b=rqCWmZWESzs1S2Njd9eaqzopBBlCO9oexSdaImQ5EJnEPBGBJkobo14Bh2H882o8WE oOjL4kXASpCzgSgDY7dYHiE5MarKmrjH2H9JvJdkFZ8vby1UDKWB5ZZpySrYhuFnuJnz SduwcHehvwPEsu2zVtSN+o7YaE3/R6Js2OyfCxfJpG8k6GA7vYxBcjaoin1zOdLphppW GR7CD0s/TTqChyxC+dzkdCXCYNM6Eu65CNOec5fMjJnSRVuBl/AKaZB9idJqtzb6ca6f T04/g6F9lzKuB7rPFnhTxLeEU8HOtfsI5Y/dHN3xPWT6P2fLyKBX3MV0wdozJaVhpOxR xyJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=t65dqCPU1l76vOHm7W6FbHIpgdz9VRI/oHeiqigs5q0=; b=Lh7HSZxUatH2aAGkT87RW+fXGFyYg9VFnRT4CwkyYwdZsFsw9+ssOPPEOyalK/hezM DSttB7r/RIeQh3ATuvMofadKpHKWQ2pU3RCa4s/mWRUwApmclGcndzZkogySYVD1o5b4 vAiZgb8SGHLjYalfo+jZs53wKNSB/MUNs6Y1yQYVcFa5W7w/bJdJ0MZxeA85598NaVVD pbk5mjeXWTNOqHRmQ9Rdb3Dha8cwSbZ7hnqmAzAS/CMQ3NwdNjfuYtpTJD7drNxI3LsV +QVhynXCXMqYygkYoqbxWM+Hv59lhbYZNSOzdAbxCr13ciwlcj8PhGfkSDK1z+3ECItH aw+w== X-Gm-Message-State: ANhLgQ0htDOLwwkI9ugnZg5KVCsp1bPEZjBMmtN4DQRZRTsqAn+ZHzJU r0k8uolUbpeE7xAaxQtqFFA= X-Google-Smtp-Source: ADFU+vs0+Ak7lHY3cr6PH3uVa/Fk3zCQkiJBZddrn1YUvTiBNrH5FE3mHaaCImL0x+MpmQJVJOSPlw== X-Received: by 2002:a17:902:7793:: with SMTP id o19mr9726950pll.174.1585252742913; Thu, 26 Mar 2020 12:59:02 -0700 (PDT) Received: from ast-mbp ([2620:10d:c090:400::5:c7d9]) by smtp.gmail.com with ESMTPSA id v25sm2333411pgl.55.2020.03.26.12.59.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Mar 2020 12:59:02 -0700 (PDT) Date: Thu, 26 Mar 2020 12:58:59 -0700 From: Alexei Starovoitov To: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= Cc: Andrii Nakryiko , John Fastabend , Jakub Kicinski , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , "David S. Miller" , Jesper Dangaard Brouer , Lorenz Bauer , Andrey Ignatov , Networking , bpf Subject: Re: [PATCH bpf-next 1/4] xdp: Support specifying expected existing program when attaching XDP Message-ID: <20200326195859.u6inotgrm3ubw5bx@ast-mbp> References: <87tv2f48lp.fsf@toke.dk> <87h7ye3mf3.fsf@toke.dk> <87tv2e10ly.fsf@toke.dk> <87369wrcyv.fsf@toke.dk> <87pncznvjy.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87pncznvjy.fsf@toke.dk> Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, Mar 26, 2020 at 01:35:13PM +0100, Toke Høiland-Jørgensen wrote: > > Additionally, in the case where there is *not* a central management > daemon (i.e., what I'm implementing with libxdp), this would be the flow > implemented by the library without bpf_link: > > 1. Query kernel for current BPF prog loaded on $IFACE > 2. Sanity-check that this program is a dispatcher program installed by > libxdp > 3. Create a new dispatcher program with whatever changes we want to do > (such as adding another component program). > 4. Atomically replace the old program with the new one using the netlink > API in this patch series. in this model what stops another application that is not using libdispatcher to nuke dispatcher program ? > Whereas with bpf_link, it would be: > > 1. Find the pinned bpf_link for $IFACE (e.g., load from > /sys/fs/bpf/iface-links/$IFNAME). > 2. Query kernel for current BPF prog linked to $LINK > 3. Sanity-check that this program is a dispatcher program installed by > libxdp > 4. Create a new dispatcher program with whatever changes we want to do > (such as adding another component program). > 5. Atomically replace the old program with the new one using the > LINK_UPDATE bpf() API. whereas here dispatcher program is only accessible to libdispatcher. Instance of bpffs needs to be known to libdispatcher only. That's the ownership I've been talking about. As discussed early we need a way for _human_ to nuke dispatcher program, but such api shouldn't be usable out of application/task.