Lines Matching refs:program
31 This crate contains a virtual machine for eBPF program execution. BPF, as in
90 Here are the steps to follow to run an eBPF program with rbpf:
93 back on this later. When creating the VM, pass the eBPF program as an
97 3. If you want a JIT-compiled program, compile it.
98 4. Execute your program: either run the interpreter or call the JIT-compiled
103 consequence, most of the load and store instructions of the program are
105 kernel, the eBPF program does not immediately access this data area: initially,
108 the end of the packet data area. So the program first loads those pointers from
115 * `struct EbpfVmMbuffer` mimics the kernel. When the program is run, the
123 internal buffer that is passed to the program. The user has to indicate the
124 offset values at which the eBPF program expects to find the start and the end
125 of packet data in the buffer. On calling the function that runs the program
128 packet data the program is called upon.
131 No metadata buffer is involved, the eBPF program directly receives the
135 * `struct EbpfVmNoData` does not take any data. The eBPF program takes no
161 rbpf::EbpfVmRaw` (wrapped in a `Result`). When a program is loaded, it is
169 each time the program is executed. Other structs do not use this mechanism and
183 program after the VM instance creation. This program is checked with the
194 Note that if a program has already been loaded into the VM, setting a new
195 verifier also immediately runs it on the loaded program. However, the verifier
196 is not run if no program has been loaded (if `None` was passed to the `new()`
226 Interprets the loaded program. The function takes a reference to the packet
229 eBPF program.
235 JIT-compile the loaded program, for x86_64 architecture. If the program is to
251 Calls the JIT-compiled program. The arguments to provide are the same as for
253 the JIT-compiled program should be the same as with the interpreter, but it
254 should run faster. Note that if errors occur during the program execution, the
256 program may crash. For this reason, the functions are marked as `unsafe`.
269 // This is the eBPF program, in the form of bytecode instructions.
280 // The eBPF program is passed to the constructor.
283 // Execute (interpret) the program. No argument required for this VM.
314 // This time we JIT-compile the program.
318 // data must be passed to the function that executes the program.
353 // This eBPF VM is for program that use a metadata buffer.
360 // Here again we JIT-compile the program.
390 which the eBPF program expects to find those pointers, and the VM handles the
392 for each run of the program.
402 // Load a program from an ELF file, e.g. compiled from C to eBPF with
412 // Here we assume the eBPF program is in the ELF section called
446 // and end must be stored: these are the offsets at which the program will
450 // We register a helper function, that can be called by the program, into
547 let mut program = BpfCode::new();
548 program.add(Source::Imm, Arch::X64).set_dst(1).set_imm(0x605).push()
612 * When an error occurs while a program is run by uBPF, the function running the
613 program silently returns the maximum value as an error code, while rbpf
617 program, is not handled in the same way.
619 * The distinct structs permitting to run program either on packet data, or with
645 * Tail calls (“long jumps” from an eBPF program into another) are not
655 ### What about program validation?
671 JIT-compiled program tries to perform unauthorized memory accesses. Usually, it
672 could be a good idea to test your program with the interpreter first.
674 Oh, and if your program has infinite loops, even with the interpreter, you're
681 * The JIT compiler produces an unsafe program: memory access are not tested at