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=-11.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 E2B58C10F14 for ; Tue, 8 Oct 2019 08:09:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BBB9720867 for ; Tue, 8 Oct 2019 08:09:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730472AbfJHIJj convert rfc822-to-8bit (ORCPT ); Tue, 8 Oct 2019 04:09:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54738 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730309AbfJHIJi (ORCPT ); Tue, 8 Oct 2019 04:09:38 -0400 Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AA7501108 for ; Tue, 8 Oct 2019 08:09:37 +0000 (UTC) Received: by mail-lf1-f71.google.com with SMTP id y27so2084982lfg.21 for ; Tue, 08 Oct 2019 01:09:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=kYDmbLHk/9d7NfrTCWV0Mv6CJV1qIpwez3d+yPbTwTA=; b=T7t9HIiP+jtRylNCxbngrzmp7r5Vq6NhzT1uiLXaMsQBLtdnPWQZuOKAyUjkwH6x+D TvWmsHPcaBW4tfKpdooOL2c/RlxCUqPNkvtwN0jsP9Di2guhSXoU3Y6O8GWEfKevn/jC C2sc2d+P4GgG9Xv9B5exgAmt9xRjG4QyJWvtxBWCqcMSw1pEFVC7QwioobmJc8zZvccE 36/6IiREv44x5wq5pUxlLhdeL0Zg8ILeFu+Nq+QdiJoHQB3K74khO9eRZbJ41qkIe45G CQYD9Stkj0DikuGHjuXF8AZPbZQ9564PRE3bQX09NLPIld/zh8ScdkgEpglIDm2WATwh KT3Q== X-Gm-Message-State: APjAAAU3h+LREVydR3yiAoRhQNot2V78dmP4OLS0vY4odC3Yx+hhZ0UO ztPh5FeX/65lbpUgxOK8Zm9eNhNaFA6W0LUsizVWldmAXGgpaRO7o9gdDLscsWigF7ZEXFobGAr /9GfWdx4DADom X-Received: by 2002:ac2:46d0:: with SMTP id p16mr19089041lfo.190.1570522176171; Tue, 08 Oct 2019 01:09:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqxAle2Dm5tkCYnO9J0WNp0pWXk447zxc1i+Ur/5bkOCZdo2MGSXCFM3n4kvLgPWHNE+pTpZ6Q== X-Received: by 2002:ac2:46d0:: with SMTP id p16mr19089017lfo.190.1570522175832; Tue, 08 Oct 2019 01:09:35 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id m6sm3807131ljj.3.2019.10.08.01.09.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Oct 2019 01:09:35 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 5ACB218063D; Tue, 8 Oct 2019 10:09:34 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Daniel Borkmann Cc: Alexei Starovoitov , Martin KaFai Lau , Song Liu , Yonghong Song , Marek Majkowski , Lorenz Bauer , Alan Maguire , Jesper Dangaard Brouer , David Miller , netdev@vger.kernel.org, bpf@vger.kernel.org Subject: Re: [PATCH bpf-next v3 2/5] bpf: Add support for setting chain call sequence for programs In-Reply-To: <20191007203855.GE27307@pc-66.home> References: <157046883502.2092443.146052429591277809.stgit@alrua-x1> <157046883723.2092443.3902769602513209987.stgit@alrua-x1> <20191007203855.GE27307@pc-66.home> X-Clacks-Overhead: GNU Terry Pratchett Date: Tue, 08 Oct 2019 10:09:34 +0200 Message-ID: <87pnj7lku9.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org Daniel Borkmann writes: > On Mon, Oct 07, 2019 at 07:20:37PM +0200, Toke Høiland-Jørgensen wrote: >> From: Toke Høiland-Jørgensen >> >> This adds support for setting and deleting bpf chain call programs through >> a couple of new commands in the bpf() syscall. The CHAIN_ADD and CHAIN_DEL >> commands take two eBPF program fds and a return code, and install the >> 'next' program to be chain called after the 'prev' program if that program >> returns 'retcode'. A retcode of -1 means "wildcard", so that the program >> will be executed regardless of the previous program's return code. >> >> >> The syscall command names are based on Alexei's prog_chain example[0], >> which Alan helpfully rebased on current bpf-next. However, the logic and >> program storage is obviously adapted to the execution logic in the previous >> commit. >> >> [0] https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git/commit/?h=prog_chain&id=f54f45d00f91e083f6aec2abe35b6f0be52ae85b&context=15 >> >> Signed-off-by: Alan Maguire >> Signed-off-by: Toke Høiland-Jørgensen >> --- >> include/uapi/linux/bpf.h | 10 ++++++ >> kernel/bpf/syscall.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 88 insertions(+) >> >> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h >> index 1ce80a227be3..b03c23963af8 100644 >> --- a/include/uapi/linux/bpf.h >> +++ b/include/uapi/linux/bpf.h >> @@ -107,6 +107,9 @@ enum bpf_cmd { >> BPF_MAP_LOOKUP_AND_DELETE_ELEM, >> BPF_MAP_FREEZE, >> BPF_BTF_GET_NEXT_ID, >> + BPF_PROG_CHAIN_ADD, >> + BPF_PROG_CHAIN_DEL, >> + BPF_PROG_CHAIN_GET, >> }; >> >> enum bpf_map_type { >> @@ -516,6 +519,13 @@ union bpf_attr { >> __u64 probe_offset; /* output: probe_offset */ >> __u64 probe_addr; /* output: probe_addr */ >> } task_fd_query; >> + >> + struct { /* anonymous struct used by BPF_PROG_CHAIN_* commands */ >> + __u32 prev_prog_fd; >> + __u32 next_prog_fd; >> + __u32 retcode; >> + __u32 next_prog_id; /* output: prog_id */ >> + }; >> } __attribute__((aligned(8))); >> >> /* The description below is an attempt at providing documentation to eBPF >> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c >> index b8a203a05881..be8112e08a88 100644 >> --- a/kernel/bpf/syscall.c >> +++ b/kernel/bpf/syscall.c >> @@ -2113,6 +2113,79 @@ static int bpf_prog_test_run(const union bpf_attr *attr, >> return ret; >> } >> >> +#define BPF_PROG_CHAIN_LAST_FIELD next_prog_id >> + >> +static int bpf_prog_chain(int cmd, const union bpf_attr *attr, >> + union bpf_attr __user *uattr) >> +{ >> + struct bpf_prog *prog, *next_prog, *old_prog; >> + struct bpf_prog **array; >> + int ret = -EOPNOTSUPP; >> + u32 index, prog_id; >> + >> + if (CHECK_ATTR(BPF_PROG_CHAIN)) >> + return -EINVAL; >> + >> + /* Index 0 is wildcard, encoded as ~0 by userspace */ >> + if (attr->retcode == ((u32) ~0)) >> + index = 0; >> + else >> + index = attr->retcode + 1; >> + >> + if (index >= BPF_NUM_CHAIN_SLOTS) >> + return -E2BIG; >> + >> + prog = bpf_prog_get(attr->prev_prog_fd); >> + if (IS_ERR(prog)) >> + return PTR_ERR(prog); >> + >> + /* If the chain_calls bit is not set, that's because the chain call flag >> + * was not set on program load, and so we can't support chain calls. >> + */ >> + if (!prog->chain_calls) >> + goto out; >> + >> + array = prog->aux->chain_progs; >> + >> + switch (cmd) { >> + case BPF_PROG_CHAIN_ADD: >> + next_prog = bpf_prog_get(attr->next_prog_fd); >> + if (IS_ERR(next_prog)) { >> + ret = PTR_ERR(next_prog); >> + break; >> + } >> + old_prog = xchg(array + index, next_prog); >> + if (old_prog) >> + bpf_prog_put(old_prog); >> + ret = 0; >> + break; > > How are circular dependencies resolved here? Seems the situation is > not prevented, so progs unloaded via XDP won't get the __bpf_prog_free() > call where they then drop the references of all the other progs in the > chain. Yeah, that's true. My plan was to just walk the "call graph" on insert and reject any circular inserts. Just haven't gotten around to adding that yet; will fix that in the next version. -Toke