Hi Quentin,
On 04/15/2016 12:07 PM, Quentin Monnet wrote:
When a new BPF traffic control filter or action is set up with tc, the
bytecode is sent back to userspace through a netlink socket for cBPF, but
not for eBPF (the file descriptor pointing to the object file containing
the bytecode is sent instead).
This patch makes cls_bpf and act_bpf modules send the bytecode for eBPF as
well (in addition to the file descriptor).
New BPF flags are used in order to differenciate what BPF version is in
use, so that userspace tools can process the bytecode properly.
Once the series is accepted and merged, it is intended to submit a patch
for the iproute2 package, so as to fix tc utility so as to use the new
flags and to display the bytecode in eBPF format when needed. This tc
patch is already available at:
https://github.com/6WIND/iproute2/commits/netlink_eBPF
Thanks for working on this, but it's unfortunately not that easy. Let
me ask, what would be the intended use-case to dump the insns?
I'm asking because if you dump them as-is, then a reinject at a later
time of that bytecode back into the kernel will most likely be rejected
by the verifier.
This is because on load time, verifier does rewrites/expansion on some
of the insns (f.e. map pointers, helper functions, ctx access etc, see
also appendix in [1]), so the code as seen in the kernel would need to
be sanitized first.
Also, how would you make sense/transform maps into a meaningful
representation (probably possible to find a scheme when they are pinned)?
Another possibility is that such programs need to be pinned (can be done
easily by tc in the background) and then implement a CRIU facility into
the bpf(2) syscall to retrieve them. tc could make use of this w/o too
much effort, and at the same time it would help CRIU folks, too. It
also seems cleaner to have only one central api (bpf(2)) to dump them,
but needs a bit of thought.
Thanks & cheers,
Daniel
[1]
http://www.netdevconf.org/1.1/proceedings/slides/borkmann-tc-classifier-cls-bpf.pdf
Quentin Monnet (2):
act_bpf: send back eBPF bytecode through netlink socket
cls_bpf: send back eBPF bytecode through netlink socket
include/uapi/linux/pkt_cls.h | 1 +
include/uapi/linux/tc_act/tc_bpf.h | 1 +
net/sched/act_bpf.c | 23 +++++++++++++++++++++++
net/sched/cls_bpf.c | 25 +++++++++++++++++++++++--
4 files changed, 48 insertions(+), 2 deletions(-)
