Retrieve the latest RST ISA doc from the "update" branch in the GitHub repository (currently used for the PR for updating the document)
Generate a JSON list of valid instructions from the RST document
Check ELF file sections for validity against the list of instructions. The checks currently include:
Checking that we have known opcodes with valid src and imm fields, as mentioned in the table in the Appendix of the RST doc.
For 0x18 (load double word + extended instructions): checking that 0x18 opcodes are followed by 0x00 opcodes, and conversely that 0x00 are always preceeded by 0x18.
Run the previous script as a batch on all sections for all .o files in a directory (example use case: run on all Cilium programs)
This is work in progress and should not be considered an official validation tool at this stage.
Once the eBPF specification gets closer to a final version, we will probably stop converting the table from the RST file and keep a reference JSON list instead (so we can also add constraints on the offset and destination register fields). In the meantime, it is easier to pull the latest adjustments this way.
Besides validation of existing programs, the scripts can be helpful to check we cover instructions existing today in deployed eBPF programs.
Add a set of scripts to:
Retrieve the latest RST ISA doc from the "update" branch in the GitHub repository (currently used for the PR for updating the document)
Generate a JSON list of valid instructions from the RST document
Check ELF file sections for validity against the list of instructions. The checks currently include:
src
andimm
fields, as mentioned in the table in the Appendix of the RST doc.0x18
(load double word + extended instructions): checking that 0x18 opcodes are followed by0x00
opcodes, and conversely that0x00
are always preceeded by0x18
.Run the previous script as a batch on all sections for all .o files in a directory (example use case: run on all Cilium programs)
This is work in progress and should not be considered an official validation tool at this stage.
Once the eBPF specification gets closer to a final version, we will probably stop converting the table from the RST file and keep a reference JSON list instead (so we can also add constraints on the offset and destination register fields). In the meantime, it is easier to pull the latest adjustments this way.
Besides validation of existing programs, the scripts can be helpful to check we cover instructions existing today in deployed eBPF programs.