kfl / ebpf-tools Goto Github PK

Test that uBPF can run the code we produce.

The Instruction type in Ebpf.Asm with an annotation construction. For instance:

data Instruction =
    ...
  | Annotation String  

Alternatively Instruction could be parameterised with the kind of annotations:

data Instruction anno =
    ...
  | Annotation anno 

Likewise the concrete syntax should support annotations. For instance by using the prefix ;;*:

; a normal comment
;;* an annotation comment
;;* assume { r1 != 0 }
add r0 r1
exit

Implement exporting an assembled eBPF bytecode program to an ELF object, similar to e.g. clang -target bpf someProgram -o someProgram.o.

This would allow us to use tools like bpftool to load programs as well as dump both their xlated and JIT'ed versions.
It might be useful for asserting correctness in ebpf-tools, as well as making it easier to use ebpf-tools with projects like the PREVAIL-verifier and uBPF. (Although uBPF accepts non-ELF raw bytecode).

I am unsure of the extent of this proposal, but I am quite certain it amounts to more than "wrap the bytecode in a header".

LLVM has chosen an unconventional syntax for their eBPF assembly syntax. And this style is also used for output by, for instance, bpftool. Thus it makes sense to support this syntax both as input and output.

Add support for labels in the assembly format.

Complete the Decode module, and extend the CLI with a disassembly command.

• Support atomic operations
• Support absolute and indirect loads
• Support tail calls

The are too many eBPF assembly syntaxes (see also #8).

We should follow uBPF's lead and match GCC's assembly format iovisor/ubpf#250

• GCC prefixes register names with %.
• Match opcode names see https://sourceware.org/binutils/docs-2.42/as.html#BPF_002dDependent and https://gcc.gnu.org/wiki/BPFBackEnd

Now that we have a working test-suite, we should set up CI so that every commit is tested.

We should probably use the Test supported GHC versions action or something like that, so that we can catch unintentional regressions in supported GHC versions.

I Started using the Helpers module and noticed for 64-Bit they are defined as such:

add64_i :: Reg -> Imm32 -> Instruction
add64_i dst imm = Binary B64 Add dst (Right $ fromIntegral imm)

should it not be:

add64_i :: Reg -> Imm64 -> Instruction

Or have i misunderstood something?

Add at least some sort minimal test suite.

Currently the level of "testing" is eyeballing the binary output.