netdev - Re: [PATCH v4 bpf-next 00/14] net: netfilter: add kfunc helper to update ct timeout

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]

Date:   Mon, 13 Jun 2022 21:44:13 +0530
From:   Kumar Kartikeya Dwivedi <memxor@...il.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Lorenzo Bianconi <lorenzo@...nel.org>, bpf@...r.kernel.org,
        netdev@...r.kernel.org, ast@...nel.org, daniel@...earbox.net,
        andrii@...nel.org, davem@...emloft.net, kuba@...nel.org,
        edumazet@...gle.com, pabeni@...hat.com, pablo@...filter.org,
        fw@...len.de, netfilter-devel@...r.kernel.org,
        lorenzo.bianconi@...hat.com, brouer@...hat.com, toke@...hat.com,
        yhs@...com
Subject: Re: [PATCH v4 bpf-next 00/14] net: netfilter: add kfunc helper to
 update ct timeout

On Sun, Jun 12, 2022 at 01:41:17AM IST, Alexei Starovoitov wrote:
> On Thu, May 26, 2022 at 11:34:48PM +0200, Lorenzo Bianconi wrote:
> > Changes since v3:
> > - split bpf_xdp_ct_add in bpf_xdp_ct_alloc/bpf_skb_ct_alloc and
> >   bpf_ct_insert_entry
> > - add verifier code to properly populate/configure ct entry
> > - improve selftests
>
> Kumar, Lorenzo,
>
> are you planning on sending v5 ?
> The patches 1-5 look good.
> Patch 6 is questionable as Florian pointed out.

Yes, it is almost there.

> What is the motivation to allow writes into ct->status?

It will only be allowed for ct from alloc function, after that ct = insert(ct)
releases old one with new read only ct. I need to recheck once again with the
code what other bits would cause problems on insert before I rework and reply.

> The selftest doesn't do that anyway.

Yes, it wasn't updated, we will do that in v5.

> Patch 7 (acquire-release pairs) is too narrow.
> The concept of a pair will not work well. There could be two acq funcs and one release.

That is already handled (you define two pairs: acq1, rel and acq2, rel).
There is also an example: bpf_ct_insert_entry -> bpf_ct_release,
bpf_xdp_ct_lookup -> ct_release.

> Please think of some other mechanism. Maybe type based? BTF?
> Or encode that info into type name? or some other way.

Hmm, ok. I kinda dislike this solution too. The other idea that comes to mind is
encapsulating nf_conn into another struct and returning pointer to that:

	struct nf_conn_alloc {
		struct nf_conn ct;
	};

	struct nf_conn_alloc *bpf_xdp_ct_alloc(...);
	struct nf_conn *bpf_ct_insert_entry(struct nf_conn_alloc *act, ...);

Then nf_conn_alloc gets a different BTF ID, and hence the type can be matched in
the prototype. Any opinions?

--
Kartikeya