Can't kretprobe events be dropped? Wouldn't that leak?
On Wed, Nov 23, 2016 at 6:48 AM, Alban Crequy via iovisor-dev <[email protected]> wrote: > 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 _______________________________________________ iovisor-dev mailing list [email protected] https://lists.iovisor.org/mailman/listinfo/iovisor-dev
