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 521AFC4332F for ; Thu, 26 May 2022 21:46:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244735AbiEZVqS (ORCPT ); Thu, 26 May 2022 17:46:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60112 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230141AbiEZVqQ (ORCPT ); Thu, 26 May 2022 17:46:16 -0400 Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2a0a:51c0:0:12e:520::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 479D51F8; Thu, 26 May 2022 14:46:14 -0700 (PDT) Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.92) (envelope-from ) id 1nuLIs-0008H6-Ef; Thu, 26 May 2022 23:45:58 +0200 Date: Thu, 26 May 2022 23:45:58 +0200 From: Florian Westphal To: Lorenzo Bianconi Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, davem@davemloft.net, kuba@kernel.org, edumazet@google.com, pabeni@redhat.com, pablo@netfilter.org, fw@strlen.de, netfilter-devel@vger.kernel.org, lorenzo.bianconi@redhat.com, brouer@redhat.com, toke@redhat.com, memxor@gmail.com, yhs@fb.com Subject: Re: [PATCH v4 bpf-next 06/14] bpf: Whitelist some fields in nf_conn for BPF_WRITE Message-ID: <20220526214558.GA31193@breakpoint.cc> References: <2954ab26de09afeecf3a56ba93624f9629072102.1653600578.git.lorenzo@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2954ab26de09afeecf3a56ba93624f9629072102.1653600578.git.lorenzo@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Lorenzo Bianconi wrote: > From: Kumar Kartikeya Dwivedi > > Since we want to allow user to set some fields in nf_conn after it is > allocated but before it is inserted, we can permit BPF_WRITE for normal > nf_conn, and then mark return value as read only on insert, preventing > further BPF_WRITE. This way, nf_conn can be written to using normal > BPF instructions after allocation, but not after insertion. > > Note that we special nf_conn a bit here, inside the btf_struct_access > callback for XDP and TC programs. Since this is the only struct for > these programs requiring such adjustments, making this mechanism > more generic has been left as an exercise for a future patch adding > custom callbacks for more structs. Are you sure this is safe? As far as I can see this allows nf_conn->status = ~0ul. I'm fairly sure this isn't a good idea, see nf_ct_delete() for example.