On Fri, Apr 15, 2022 at 10:49 AM Jakub Sitnicki <jakub@xxxxxxxxxxxxxx> wrote: > > On Mon, Apr 11, 2022 at 11:44 AM -07, Stanislav Fomichev wrote: > > On Sat, Apr 9, 2022 at 11:10 AM Jakub Sitnicki <jakub@xxxxxxxxxxxxxx> wrote: > > [...] > > >> [^1] It looks like we can easily switch from cgroup->bpf.progs[] from > >> list_head to hlist_head and save some bytes! > >> > >> We only access the list tail in __cgroup_bpf_attach(). We can > >> either iterate over the list and eat the cost there or push the new > >> prog onto the front. > >> > >> I think we treat cgroup->bpf.progs[] everywhere like an unordered > >> set. Except for __cgroup_bpf_query, where the user might notice the > >> order change in the BPF_PROG_QUERY dump. > > > > > > [...] > > > >> [^2] Unrelated, but we would like to propose a > >> CGROUP_INET[46]_POST_CONNECT hook in the near future to make it > >> easier to bind UDP sockets to 4-tuple without creating conflicts: > >> > >> https://github.com/cloudflare/cloudflare-blog/tree/master/2022-02-connectx/ebpf_connect4 > > > > Do you think those new lsm hooks can be used instead? If not, what's missing? > > Same as for CGROUP_INET hooks, there is no post-connect() LSM hook. There is inet_conn_established, but looks like it triggers only for tcp. Selinux is the only user, so I'm assuming we should be able to extend it as needed? I'm not sure how far we can go with adding custom hooks :-( So moving to fentry/lsm seems like the way to go. Maybe we should follow up with a per-cgroup fentry as well :-D > Why are we looking for a post-connect hook? > > Having a pre- and a post- connect hook, would allow us to turn the whole > connect() syscall into a critical section with synchronization done in > BPF - lock on pre-connect, unlock on post-connect. > > Why do we want to serialize connect() calls? > > To check for 4-tuple conflict with an existing unicast UDP socket, in > which case we want fail connect() if there is a conflict. > > That said, ideally we would rather have a mechanism like > IP_BIND_ADDRESS_NO_PORT, but for UDP, and one that allows selecting both > an local IP and port. > > We're hoping to put together an RFC sometime this quarter.
