On Tue, Nov 29, 2016 at 03:38:18PM +0000, Jakub Kicinski wrote: > > >>> [...] > > > So next step is to improve verifier messages to be more human friendly. > > > The step after is to introduce BPF_COMMENT pseudo instruction > > > that will be ignored by the interpreter yet it will contain the text > > > of original source code. Then llvm-objdump step won't be necessary. > > > The bpf loader will load both instructions and pieces of C sources. > > > Then verifier errors should be even easier to read and humans > > > can easily understand the purpose of the program. > > > > So the BPF_COMMENT pseudo insn will get stripped away from the insn array > > after verification step, so we don't need to hold/account for this mem? I > > assume in it's ->imm member it will just hold offset into text blob? > > Associating any form of opaque data with programs always makes me > worried about opening a side channel of communication with a specialized > user space implementations/compilers. But I guess if the BPF_COMMENTs > are stripped in the verifier as Daniel assumes drivers and JITs will > never see it.
yes. the idea that it's a comment. It can contain any text, not only C code, but any other language. It's definitely going to be stripped before JITs and kernel will not make any safety or translation decisions based on such comment. > Just to clarify, however - is there any reason why pushing the source > code into the kernel is necessary? Or is it just for convenience? > Provided the user space loader has access to the debug info it should > have no problems matching the verifier output to code lines? correct. just for convenience. The user space has to keep .o around, since it can crash, would have to reload and so on. Only for some script that ssh-es into servers and wants to see what is being loaded, it might help to dump full asm and these comments along with prog_digest that Daniel is working on in parallel. Alternatively instead of doing BPF_COMMENT we can load the whole .o as-is into bpffs as a blob. Later (based on digest) the kernel can dump such .o back for user space to run objdump on. It all can be done without kernel involvement. Like tc command can copy .o and so on. But not everything is using tc. Another alternative is to do a decompiler from bpf binary into meaningful C code. It's not trivial and names will be lost. bpf_comment approach is pretty cheap from kernel point of view and greatly helps visibility when users don't cheat with debug info.
