←All SIMDs
SIMD · 0377

eBPF ISA compatibility

ReviewCoreStandardOctober 9, 2025
by Lucas Steuernagel (Anza), Alexander Meißner (Anza)
View on GitHub

Summary

This SIMD introduces instruction set architecture (ISA) changes to make the sBPF virtual machine compatible with the latest existing version of eBPF ISA generated by its LLVM backend.

It reverts past ISA changes, modifies the encoding of existing instructions and brings new instructions to the Solana virtual machine.

Motivation

The eBPF target on the Rust compiler emits code by default for eBPFv1, whose only incompatibility with the Solana virtual machine is the callx instruction. Aiming to prioritize Solana programs and decrease their CU consumption, we want to be compatible with at least the current eBPF version (v3), which brings in new instructions. In order for that to be possible, we must modify our virtual machine to support eBPF integrally.

Dependencies

This proposal depends on the following previously accepted proposals:

  • [SIMD-0178]: SBPF Static Syscalls

  • [SIMD-0189]: SBPF stricter ELF headers

    This SIMD requires static syscalls which requires stricter ELF headers.

[SIMD-0178]: https://github.com/solana-foundation/solana-improvement-documents/pull/178 [SIMD-0189]: https://github.com/solana-foundation/solana-improvement-documents/pull/189

New Terminology

The set containing these new instructions will form an sBPFv3 program.

Detailed Design

ELF Identification

Programs containing the instructions mentioned in this SIMD must have the 0x03 value in the e_flags field of their header.

JMP32 instruction class

The JMP32 instruction class utilizes 32 bit wide operands for the same operations as the JMP class.

The following opcodes must be allowed in the verifier and the virtual machine must implement the behavior described below for each one of them.

  • JEQ32_IMM -> opcode = 0x16 -> pc += offset if dst as u32 == IMM as u32
  • JGT32_IMM -> opcode = 0x26 -> pc += offset if dst as u32 > IMM as u32
  • JGE32_IMM -> opcode = 0x36 -> pc += offset if dst as u32 >= IMM as u32
  • JSET32_IMM -> opcode = 0x46 -> pc += offset if (dst as u32 & IMM as u32) != 0
  • JNE32_IMM -> opcode = 0x56 -> pc += offset if dst as u32 != IMM as u32
  • JSGT32_IMM -> opcode = 0x66 -> pc += offset if dst as i32 > IMM as i32
  • JSGE32_IMM -> opcode = 0x76 -> pc += offset if dst as i32 > IMM as i32
  • JLT32_IMM -> opcode = 0xa6 -> pc += offset if dst as u32 < IMM as u32
  • JLE32_IMM -> opcode = 0xb6 -> pc += offset if dst as u32 <= IMM as u32
  • JSLT32_IMM -> opcode = 0xc6 -> pc += offset if dst as i32 < IMM as i32
  • JSLE32_IMM -> opcode = 0xd6 -> pc += offset if dst as i32 <= IMM as i32
  • JEQ32_REG -> opcode = 0x1e -> pc += offset if dst as u32 == src as u32
  • JGT32_REG -> opcode = 0x2e -> pc += offset if dst as u32 > src as u32
  • JGE32_REG -> opcode = 0x3e -> pc += offset if dst as u32 >= src as u32
  • JSET32_REG -> opcode = 0x4e -> pc += offset if (dst as u32 & src as u32) != 0
  • JNE32_REG -> opcode = 0x56 -> pc += offset if dst as u32 != src as u32
  • JSGT32_REG -> opcode = 0x66 -> pc += offset if dst as i32 > src as i32
  • JSGE32_REG -> opcode = 0x76 -> pc += offset if dst as i32 > src as i32
  • JLT32_REG -> opcode = 0xa6 -> pc += offset if dst as u32 < src as u32
  • JLE32_REG -> opcode = 0xb6 -> pc += offset if dst as u32 <= src as u32
  • JSLT32_REG -> opcode = 0xc6 -> pc += offset if dst as i32 < src as i32
  • JSLE32_REG -> opcode = 0xd6 -> pc += offset if dst as i32 <= src as i32

callx encoding

The encoding of callx must change so that the register containing the address to jump to is in the destination register.

  • callx -> opcode = 0x9d -> pc = dst

Stack frame gaps

The virtual machine feature of stack gaps must be disabled for sBPFv3 programs.

Alternatives Considered

We have considered diverging from the eBPF standard by introducing new opcodes and creating specific instructions to the Solana environment. We discarded such an approach to be compatible with the existing LLVM eBPF code generation.

Another consideration was bringing new eBPFv4 instructions to the Solana environment. They are a superset of eBPFv3 and does not conflict with it, so any additions may be included in the future without a breaking change.

Impact

These changes permit a straightforward management of the compiler toolchain, permitting the usage of most of existing upstream tooling.

Security Considerations

None