Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standardizing BPF assembly language? #71

Open
dthaler opened this issue Jan 23, 2024 · 0 comments
Open

Standardizing BPF assembly language? #71

dthaler opened this issue Jan 23, 2024 · 0 comments

Comments

@dthaler
Copy link
Collaborator

dthaler commented Jan 23, 2024

At LSF/MM/BPF 2023, Jose gave a presentation about BPF assembly language (http://vger.kernel.org/bpfconf2023_material/compiled_bpf.txt).

Jose wrote in that link:

There are two dialects of BPF assembler in use today:

  • A "pseudo-c" dialect (originally "BPF verifier format")
    : r1 = *(u64 *)(r2 + 0x00f0)
    : if r1 > 2 goto label
    : lock *(u32 *)(r2 + 10) += r3

  • An "assembler-like" dialect
    : ldxdw %r1, [%r2 + 0x00f0]
    : jgt %r1, 2, label
    : xaddw [%r2 + 2], r3

During Jose's talk, I discovered that uBPF didn't quote match the second dialect and submitted a bug report. By the time the conference was over, uBPF had been updated to match GCC, so that discussion worked to reduce the number of variants.

As more instructions get added and supported by more tools and compilers there's the risk of even more variants unless it's standardized.

Hence I'd recommend that BPF assembly language get documented in some WG draft. If folks agree with that premise, the first question is then: which document?
One possible answer would be the ISA document that specifies the instructions, since that would the IANA registry could list the assembly for each instruction, and any future documents that add instructions would necessarily need to specify the assembly for them, preventing variants from springing up for new instructions.

A second question would be, which dialect(s) to standardize. Jose's link above argues that the second dialect should be the one standardized (tools are free to support multiple dialects for backwards compat if they want). See the link for rationale.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant