Hi Daniel, David, 2017-02-03 (15:28 -0700) ~ David Ahern <d...@cumulusnetworks.com> > On 2/3/17 2:09 PM, Daniel Borkmann wrote: >> On 02/03/2017 09:38 PM, David Ahern wrote: >>> Similar to classic bpf, support saving original ebpf instructions >>> >>> Signed-off-by: David Ahern <d...@cumulusnetworks.com> >> >> Not convinced that this is in the right direction, this not only >> *significantly* >> increases mem footprint for each and every program, but also when you dump >> this, >> then map references from relocs inside the insns are meaningless (f.e. what >> about >> prog arrays used in tail calls?), so things like criu also won't be able to >> use >> this kind of interface for dump and restore. If it's just for debugging, then >> why not extend the existing tracing infrastructure around bpf that was >> started >> with intention to gain more visibility. > > > Yes, saving the original bpf increases the memory footprint. If you noticed, > a kmemdup is used for the exact instruction size (no page round up). Right > now programs are limited to a single page, so worst case is an extra page > per program. I am open to other suggestions. For example, bpf_prog is rounded > up to a page which means there could be room at the end of the page for the > original instructions. This is definitely true for the ip vrf programs which > will be < 32 instructions even with the namespace checking and the > conversions done kernel side. > > Tracepoints will not solve the problem for me for a number of reasons. > Tracepoints have to be hit to return data, and there is no way the tracepoint > can return relevant information for me to verify that the correct filter was > downloaded. I want the original code. I want to audit what was installed. In > my case there could be N VRFs, and I want 'ip vrf' or ifupdown2 or any other > command to be able to verify that each cgroup has the correct program, and to > verify that the default VRF does *not* have a program installed. > > Generically, the bpf code might contain relative data but that's for the user > or decoder program to deal with. Surely there is no harm in returning the > original, downloaded bpf code to a properly privileged process. If I am > debugging some weird network behavior, I want to be able to determine what > bpf code is running where and to see what it is doing to whatever degree > possible. Saving the original code is the first part of this. >
This reminds me of that patchset I sent some time ago [1] to dump a program, and which was rejected for the same reasons. I'd like to stand with David and confirm that I am interested as well in a solution that would allow to dump the bytecode without relying on tracepoints. Quentin [1] https://www.spinics.net/lists/netdev/msg373259.html
