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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EF7A6C27C76 for ; Wed, 25 Jan 2023 10:44:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235043AbjAYKoM (ORCPT ); Wed, 25 Jan 2023 05:44:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235462AbjAYKoM (ORCPT ); Wed, 25 Jan 2023 05:44:12 -0500 Received: from 4.mo541.mail-out.ovh.net (4.mo541.mail-out.ovh.net [46.105.61.80]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BEFBA20072 for ; Wed, 25 Jan 2023 02:44:09 -0800 (PST) Received: from ex4.mail.ovh.net (unknown [10.111.172.110]) by mo541.mail-out.ovh.net (Postfix) with ESMTPS id C214725152; Wed, 25 Jan 2023 10:25:36 +0000 (UTC) Received: from localhost (37.65.8.229) by DAG10EX1.indiv4.local (172.16.2.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.17; Wed, 25 Jan 2023 11:25:35 +0100 Date: Wed, 25 Jan 2023 11:25:34 +0100 From: Quentin Deslandes To: Florian Westphal CC: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Mykola Lysenko , Shuah Khan , Dmitrii Banshchikov , , , , , Kernel Team Subject: Re: [PATCH bpf-next v3 00/16] bpfilter Message-ID: <20230125102423.vsrqn27jm3h3fvj7@dev-bpfilter1> References: <20221224000402.476079-1-qde@naccy.de> <20230103114540.GB13151@breakpoint.cc> <8773f286-74ba-4efb-4a94-0c1f91d959bd@naccy.de> <20230112031728.GL27644@breakpoint.cc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230112031728.GL27644@breakpoint.cc> X-Originating-IP: [37.65.8.229] X-ClientProxiedBy: CAS11.indiv4.local (172.16.1.11) To DAG10EX1.indiv4.local (172.16.2.91) X-Ovh-Tracer-Id: 262334681463582460 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedruddvvddgudeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggugfgjihesthekredttddtudenucfhrhhomhepsfhuvghnthhinhcuffgvshhlrghnuggvshcuoehquggvsehnrggttgihrdguvgeqnecuggftrfgrthhtvghrnhepleetleevveelhfeufeeutdegvdffgfevkeegvdfhhfejjeeghfduhfeluedvvddunecukfhppeduvdejrddtrddtrddupdefjedrieehrdekrddvvdelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpeeoqhguvgesnhgrtggthidruggvqedpnhgspghrtghpthhtohepuddprhgtphhtthhopehffiesshhtrhhlvghnrdguvgdplhhinhhugidqkhhsvghlfhhtvghsthesvhhgvghrrdhkvghrnhgvlhdrohhrghdpsghpfhesvhhgvghrrdhkvghrnhgvlhdrohhrghdplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhmvgesuhgsihhquhgvrdhsphgsrdhruhdpshhhuhgrhheskhgvrhhnvghlrdhorhhgpdhmhihkohhlrghlsehfsgdrtghomhdpphgrsggvnhhisehrvgguhhgrthdrtghomhdpkhhusggrsehkvghrnhgvlhdrohhrghdpvgguuhhmrg iivghtsehgohhoghhlvgdrtghomhdpuggrvhgvmhesuggrvhgvmhhlohhfthdrnhgvthdpjhholhhsrgeskhgvrhhnvghlrdhorhhgpdhhrgholhhuohesghhoohhglhgvrdgtohhmpdhsughfsehgohhoghhlvgdrtghomhdpkhhpshhinhhghheskhgvrhhnvghlrdhorhhgpdhjohhhnhdrfhgrshhtrggsvghnugesghhmrghilhdrtghomhdphihhshesfhgsrdgtohhmpdhsohhngheskhgvrhhnvghlrdhorhhgpdhmrghrthhinhdrlhgruheslhhinhhugidruggvvhdprghnughrihhisehkvghrnhgvlhdrohhrghdpuggrnhhivghlsehiohhgvggrrhgsohigrdhnvghtpdgrshhtsehkvghrnhgvlhdrohhrghdpnhgvthguvghvsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhkvghrnhgvlhdqthgvrghmsehmvghtrgdrtghomhdpoffvtefjohhsthepmhhoheeguddpmhhouggvpehsmhhtphhouhht Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, Jan 12, 2023 at 04:17:28AM +0100, Florian Westphal wrote: > Quentin Deslandes wrote: > > Le 03/01/2023 à 12:45, Florian Westphal a écrit : > > > You can't make this atomic from userspace perspective, the > > > get/setsockopt API of iptables uses a read-modify-write model. > > > > This refers to updating the programs from bpfilter's side. It won't > > be atomic from iptables point of view, but currently bpfilter will > > remove the program associated to a table, before installing the new > > one. This means packets received in between those operations are > > not filtered. I assume a better solution is possible. > > Ah, I see, thanks. > > > > Tentatively I'd try to extend libnftnl and generate bpf code there, > > > since its used by both iptables(-nft) and nftables we'd automatically > > > get support for both. > > > > That's one of the option, this could also remain in the kernel > > tree or in a dedicated git repository. I don't know which one would > > be the best, I'm open to suggestions. > > I can imagine that this will see a flurry of activity in the early > phase so I think a 'semi test repo' makes sense. > > Provideded license allows this, useable bits and pieces can then > be grafted on to libnftnl (or iptables or whatever). > > > > I was planning to look into "attach bpf progs to raw netfilter hooks" > > > in Q1 2023, once the initial nf-bpf-codegen is merged. > > > > Is there any plan to support non raw hooks? That's mainly out > > of curiosity, I don't even know whether that would be a good thing > > or not. > > Not sure what 'non raw hook' is. Idea was to expose > > 1. protcocol family > 2. hook number (prerouting, input etc) > 3. priority > > to userspace via bpf syscall/bpf link. > > userspace would then provide the above info to kernel via > bpf(... BPF_LINK_CREATE ) > > which would then end up doing: > -------------- > h.hook = nf_hook_run_bpf; // wrapper to call BPF_PROG_RUN > h.priv = prog; // the bpf program to run > h.pf = attr->netfilter.pf; > h.priority = attr->netfilter.priority; > h.hooknum = attr->netfilter.hooknum; > > nf_register_net_hook(net, &h); > -------------- > > After that nf_hook_slow() calls the bpf program just like any > other of the netfilter hooks. > > Does that make sense or did you have something else in mind? Sounds good to me. I thought you were referring to hooks available for the RAW table (as in `iptables --table raw...`). Thanks, Quentin