Compiling to BPF with GCC

Posted Sep 28, 2019 10:18 UTC (Sat) by smurf (subscriber, #17840)
In reply to: Compiling to BPF with GCC by mti
Parent article: Compiling to BPF with GCC

If the BPF program tries to do something nontrivial and/or useful, randomly halting it because it's overrun its instruction budget is no longer a particularly good idea.

Compiling to BPF with GCC

Posted Sep 28, 2019 11:04 UTC (Sat) by mti (subscriber, #5390) [Link]

As long as you stick to bounded loops it is quite simple to calculate an upper limit on the number of instructions that need to be executed. And it is very easy to check that the code never exceeds this upper limit. Much easier that verifying that the generated code in fact only contains bounded loops.

And you get the possibility to write unbounded loops in cases where sudden termination is acceptable.

What should happen if the limit is exceeded must be defined from case to case.

Compiling to BPF with GCC

Posted Sep 28, 2019 18:03 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

An eBPF program is not guaranteed to actually produce anything useful. There is no inherent "BPF exit code" value.

All the outside interactions are done through maps and if you forget to write a value into a map then it's no different from a BPF program being terminated by instruction count.

Compiling to BPF with GCC

Posted Oct 3, 2019 9:35 UTC (Thu) by ecree (guest, #95790) [Link]

> An eBPF program is not guaranteed to actually produce anything useful. There is no inherent "BPF exit code" value.

This is untrue. An eBPF program ends with an 'exit' instruction, and the exit code is the value of r0, which is returned to the caller of BPF_PROG_RUN(). In the case of XDP, for instance, this value will typically be an enum xdp_action value such as XDP_DROP or XDP_REDIRECT.