Verifier and stack usage

Relevant source files

• src/verifier.rs 
• src/stack.rs 
• src/lib.rs 
• tests/ubpf_verifier.rs 
• tests/misc.rs 

rbpf’s verifier is a short structural checker. It is nothing like the Linux kernel verifier: it does not track register types, pointer bounds, or termination. Programs it accepts may still be unsafe. The interpreter makes up for this with runtime memory checks; the x86_64 JIT does not.

Where it runs

• new() always uses the built-in verifier::check.
• set_program() uses whatever verifier is currently installed.
• set_verifier(v) runs v on the loaded program straight away and installs it only if that run succeeds.

A custom verifier has the type:

pub type Verifier = fn(prog: &[u8]) -> Result<(), Error>;

use rbpf::lib::{Error, ErrorKind};
use rbpf::ebpf;
 
fn verifier(prog: &[u8]) -> Result<(), Error> {
    let last_insn = ebpf::get_insn(prog, (prog.len() / ebpf::INSN_SIZE) - 1);
    if last_insn.opc != ebpf::EXIT {
        return Err(Error::new(ErrorKind::Other, "program does not end with EXIT"));
    }
    Ok(())
}
 
let mut vm = rbpf::EbpfVmNoData::new(Some(prog)).unwrap();
vm.set_verifier(verifier).unwrap();

Checks performed by verifier::check

Every error message is prefixed with [Verifier] Error:.

Limitations worth knowing:

• The final-instruction check only tests the class (BPF_JMP), so a program ending in a jump passes. The interpreter then hits unreachable!() if it runs past the end.
• Backward jumps other than off == -1 are allowed, so loops, including infinite ones, get through.
• Helper IDs are not checked. Unknown helpers fail at runtime in the interpreter and at compile time in the JITs.
• LD_DW_IMM counts as a “store” for the register check, so its dst may be 10. The interpreter will then write to r10.

Stack usage (StackVerifier)

Once verification succeeds, the VM computes a StackUsage map from function entry PCs to StackUsageType. The interpreter uses it to move r10 on local calls.

pub type StackUsageCalculator = fn(prog: &[u8], pc: usize, data: &mut dyn Any) -> u16;
 
pub fn set_stack_usage_calculator(
    &mut self,
    calculator: StackUsageCalculator,
    data: Box<dyn Any>,
) -> Result<(), Error>;

• Without a calculator, every function (PC 0 and every CALL target) gets StackUsageType::Default, which is LOCAL_FUNCTION_STACK_SIZE = 256 bytes.
• With a calculator, each function gets StackUsageType::Custom(calculator(prog, pc, data)). data is user state that is passed back on each call.
• Setting a calculator recomputes usage for the loaded program straight away.

fn calculator(_prog: &[u8], _pc: usize, _data: &mut dyn core::any::Any) -> u16 {
    16
}
vm.set_stack_usage_calculator(calculator, Box::new(())).unwrap();

stack_validate computes a target idx + 1 + imm for every CALL opcode, helper calls (src = 0) included. A custom calculator can therefore be called with PCs that are not function entries, and even with PCs outside the program. It should handle those values without panicking.