Thanks for the LSM callbacks idea, we should explore that. At the moment, we have something that works for IPv4 in most cases. Some cases with connection timeouts don't get close events, we will have to fix it getting only ESTABLISHED connections (which is what we actually want) by tracing tcp_set_state: https://github.com/weaveworks/scope/pull/2024/files#diff-5023f232702c5a1b8177be985db66b08R43
This is for monitoring the tcp connections. We don't need to know how much traffic there is, but just to be notified when a new tcp connection is created and terminated. We don't control the kernel versions, this should work on main distributions. I had a look at the size of the structs and offsets of the fields between two different kernels (Fedora 4.7.9 and Arch 4.8.8). The size of the structs are all different and there is one field at a different offset: (struct inet_sock)->inet_sport. That confirms that the eBPF program really needs to be recompiled for each kernel version in this use case. Cheers, Alban On Thu, Nov 17, 2016 at 6:47 PM, Sargun Dhillon <[email protected]> wrote: > > It might make sense to hook into the LSM callbacks > (security_socket_connect, security_socket_accept, security_sk_free, > etc..), and tcp_set_state. > > These APIs have been stable across quite a few kernel versions, and > I've been using them with success for a similar use case. As far as > precompiled BPF goes, since we know the kernel versions that we're > going to be running on (Redhat, CoreOS), we can add white labels, and > set the kernel version at load time, if the kernel we're being loaded > into is in the whitelist. > > Just curious though, what are you doing...? If this is container > network isolation, or network monitoring, you may want to look at the > Checmate / Landlock / Daniel Cgroup BPF patches on netdev. > > On Thu, Nov 17, 2016 at 9:28 AM, Alban Crequy via iovisor-dev > <[email protected]> wrote: > > Hi all, > > > > On Thu, Nov 17, 2016 at 5:54 AM, Brenden Blanco via iovisor-dev > > <[email protected]> wrote: > > [...] > >> Alban: > >> Had 4 topics from IRC (3 were discussed): > >> 1. Golang libraries for kprobe-eBPF and perf-maps > >> We agreed to fork the code in github.com/iovisor/iomodules into its own > >> go library. > >> AI: Brenden to send proposal for name of new repo > >> 2. dependencies on kernel headers for kprobe-eBPF > >> There has been some previous discussion of this in > >> github.com/iovisor/bcc/issues/421, but no substantial progress yet. > >> Another > >> alternative that Brenden proposed was to let the API accept LLVM-IR as the > >> input of a BPF() object, such that frontends could "compile" against the > >> headers offline. > >> 3. API stability for a limited set of kprobe-eBPF programs > >> We didn't discuss this, Alban would you like to give us some more context? > > > > I forgot this part. > > > > I am using kprobes / kretprobes on the following functions: > > - tcp_v4_connect > > - tcp_close > > - inet_csk_accept > > > > And I access the following structs (& fields): > > - struct sock (__sk_common) > > - struct sock_common (skc_rcv_saddr, skc_daddr, skc_dport, skc_num, skc_net) > > - struct inet_sock (inet_sport) > > - struct ns_common (inum) > > > > If I compile the eBPF program once and reuse it for future kernel, how > > likely is it that the used fields will change offsets and things might > > break? > > > > If I want to support several kernels (let's say the last Ubuntu, > > Fedora, ... kernels), how likely is it that the offsets of the fields > > above don't change and that I could reuse one pre-compiled eBPF > > program for several kernels? > > > >> 4. size of bcc.so when included in (and used from within) a container image > >> wanting to build libbcc against alpine go bindings > >> No work has been done to compile bcc using alpine base. This would be a > >> nice > >> to have if someone out there has some experience or free time. > > > > Cheers, > > Alban > > _______________________________________________ > > iovisor-dev mailing list > > [email protected] > > https://lists.iovisor.org/mailman/listinfo/iovisor-dev _______________________________________________ iovisor-dev mailing list [email protected] https://lists.iovisor.org/mailman/listinfo/iovisor-dev
