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
