netdev - Re: [PATCH bpf-next v2 1/2] net: netfilter: Make ct zone opts configurable for bpf ct helpers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20240501045931.157041-1-brad@faucet.nz>
Date: Wed,  1 May 2024 16:59:31 +1200
From: Brad Cowie <brad@...cet.nz>
To: martin.lau@...ux.dev
Cc: andrii@...nel.org, ast@...nel.org, bpf@...r.kernel.org, brad@...cet.nz,
 coreteam@...filter.org, daniel@...earbox.net, davem@...emloft.net,
 john.fastabend@...il.com, jolsa@...nel.org, kuba@...nel.org,
 lorenzo@...nel.org, memxor@...il.com, netdev@...r.kernel.org,
 netfilter-devel@...r.kernel.org, pabeni@...hat.com, pablo@...filter.org,
 sdf@...gle.com, song@...nel.org
Subject: Re: [PATCH bpf-next v2 1/2] net: netfilter: Make ct zone opts configurable for bpf ct helpers

On Fri, 26 Apr 2024 at 11:27, Martin KaFai Lau <martin.lau@...ux.dev> wrote:
> On 4/23/24 8:00 PM, Brad Cowie wrote:
> >   };
> >
> >   static int bpf_nf_ct_tuple_parse(struct bpf_sock_tuple *bpf_tuple,
> > @@ -104,11 +107,13 @@ __bpf_nf_ct_alloc_entry(struct net *net, struct bpf_sock_tuple *bpf_tuple,
> >   			u32 timeout)
> >   {
> >   	struct nf_conntrack_tuple otuple, rtuple;
> > +	struct nf_conntrack_zone ct_zone;
> >   	struct nf_conn *ct;
> >   	int err;
> >
> > -	if (!opts || !bpf_tuple || opts->reserved[0] || opts->reserved[1] ||
> > -	    opts_len != NF_BPF_CT_OPTS_SZ)
> > +	if (!opts || !bpf_tuple)
> > +		return ERR_PTR(-EINVAL);
> > +	if (!(opts_len == NF_BPF_CT_OPTS_SZ || opts_len == NF_BPF_CT_OPTS_OLD_SZ))
> >   		return ERR_PTR(-EINVAL);
> >
> >   	if (unlikely(opts->netns_id < BPF_F_CURRENT_NETNS))
> > @@ -130,7 +135,16 @@ __bpf_nf_ct_alloc_entry(struct net *net, struct bpf_sock_tuple *bpf_tuple,
> >   			return ERR_PTR(-ENONET);
> >   	}
> >
> > -	ct = nf_conntrack_alloc(net, &nf_ct_zone_dflt, &otuple, &rtuple,
> > +	if (opts_len == NF_BPF_CT_OPTS_SZ) {
> > +		if (opts->ct_zone_dir == 0)
>
> I don't know the details about the dir in ct_zone, so a question: a 0 
> ct_zone_dir is invalid and can be reused to mean NF_CT_DEFAULT_ZONE_DIR?

ct_zone_dir is a bitmask that can have two different bits set,
NF_CT_ZONE_DIR_ORIG (1) and NF_CT_ZONE_DIR_REPL (2).

The comparison function nf_ct_zone_matches_dir() in nf_conntrack_zones.h
checks if ct_zone_dir & (1 << ip_conntrack_dir dir). ip_conntrack_dir
has two possible values IP_CT_DIR_ORIGINAL (0) and IP_CT_DIR_REPLY (1).

If ct_zone_dir has a value of 0, this makes nf_ct_zone_matches_dir()
always return false which makes nf_ct_zone_id() always return
NF_CT_DEFAULT_ZONE_ID instead of the specified ct zone id.

I chose to override ct_zone_dir here and set NF_CT_DEFAULT_ZONE_DIR (3),
to make the behaviour more obvious when a user calls the bpf ct helper
kfuncs while only setting ct_zone_id but not ct_zone_dir.

> > +			opts->ct_zone_dir = NF_CT_DEFAULT_ZONE_DIR;
> > +		nf_ct_zone_init(&ct_zone,
> > +				opts->ct_zone_id, opts->ct_zone_dir, opts->ct_zone_flags);
> > +	} else {
>
> Better enforce "ct_zone_id == 0" also instead of ignoring it.

Could I ask for clarification here, do you mean changing this
else statement to:

+	} else if (opts->ct_zone_id == 0) {

Or should I be setting opts->ct_zone_id = 0 inside the else block?