Hi, 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.
The LSM callbacks (security_socket_connect etc.) are only available on CONFIG_SECURITY_NETWORK and in practice, some Linux distributions (Arch) don't have that config. Without CONFIG_SECURITY_NETWORK, the function is defined as "static inline" in the header file so we cannot hook a kprobe on it. So we kept the hook on tcp_v4_connect and similar. > 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
