Re: [PATCH] tc, bpf: add option to dump bpf verifier as C program fragment

[Stephen Hemminger <stephen@networkplumber.org>]

On Wed, 20 Jun 2018 00:13:52 +0200
Daniel Borkmann <daniel@iogearbox.net> wrote:

> On 06/18/2018 11:44 PM, David Ahern wrote:
> > On 6/18/18 2:18 PM, Jakub Kicinski wrote:  
> >> On Sun, 17 Jun 2018 08:48:41 +0000, Ophir Munk wrote:  
> >>> Similar to cbpf used within tcpdump utility with a "-d" option to dump
> >>> the compiled packet-matching code in a human readable form - tc has the
> >>> "verbose" option to dump ebpf verifier output.
> >>> Another useful option of cbpf using tcpdump "-dd" option is to dump
> >>> packet-matching code a C program fragment. Similar to this - this commit
> >>> adds a new tc ebpf option named "code" to dump ebpf verifier as C program
> >>> fragment.
> >>>
> >>> Existing "verbose" option sample output:
> >>>
> >>> Verifier analysis:
> >>> 0: (61) r2 = *(u32 *)(r1 +52)
> >>> 1: (18) r3 = 0xdeadbeef
> >>> 3: (63) *(u32 *)(r10 -4) = r3
> >>> .
> >>> .
> >>> 11: (63) *(u32 *)(r1 +52) = r2
> >>> 12: (18) r0 = 0xffffffff
> >>> 14: (95) exit
> >>>
> >>> New "code" option sample output:
> >>>
> >>> /* struct bpf_insn cls_q_code[] = { */
> >>> {0x61,    2,    1,       52, 0x00000000},
> >>> {0x18,    3,    0,        0, 0xdeadbeef},
> >>> {0x00,    0,    0,        0, 0x00000000},
> >>> .
> >>> .
> >>> {0x63,    1,    2,       52, 0x00000000},
> >>> {0x18,    0,    0,        0, 0xffffffff},
> >>> {0x00,    0,    0,        0, 0x00000000},
> >>> {0x95,    0,    0,        0, 0x00000000},
> >>>
> >>> Signed-off-by: Ophir Munk <ophirmu@mellanox.com>  
> >>
> >> Hmm... printing C arrays looks like hacky integration with some C
> >> code...  Would you not be better served by simply using libbpf in
> >> whatever is consuming this output?  
> > 
> > I was thinking the same. bpftool would provide options too -- print the
> > above, print in macro encodings and verifier. I gave an example of this
> > side by side dump at netconf 2.1. Does not look like the slides made it
> > online; see attached.  
> 
> +1, I would also doubt that this adds a lot in terms of debuggability
> when you're trying to load an object file with thousands of insns. Better
> way would be to use llvm-objdump on the obj file to get to the annotated
> disassembly, see also example in [0]. A .o to .c converter is wip for
> libbpf/bpftool as presented in [1], which should provide the flexibility
> to embedd an obj file.
> 
> Cheers,
> Daniel
> 
>   [0] http://cilium.readthedocs.io/en/latest/bpf/#llvm
>   [1] http://vger.kernel.org/netconf2018_files/AlexeiStarovoitov_netconf2018.pdf page 22

I am going to not accept this for now. Please respin for iproute2 next if
you think bpftool won't be able to handle this.