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] [day] [month] [year] [list]

Message-ID: <f3721e87-10dc-46d7-86b1-432d8afa4b21@linux.dev>
Date: Wed, 1 May 2024 15:11:09 -0700
From: Martin KaFai Lau <martin.lau@...ux.dev>
To: Brad Cowie <brad@...cet.nz>
Cc: andrii@...nel.org, ast@...nel.org, bpf@...r.kernel.org,
 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 4/30/24 9:59 PM, Brad Cowie wrote:
> 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.

Ok. make sense.

> 
>>> +			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?

Testing non zero inside the else and return error instead of silently ignoring 
it and then use nf_ct_zone_dflt:

	} else {
		if (opts->ct_zone_id)
			/* don't ignore the opts->ct_zone_id */
			return ERR_PTR(-EINVAL);
		
		ct_zone = nf_ct_zone_dflt;
	}