^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) ==============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) BPF Design Q&A
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ==============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) BPF extensibility and applicability to networking, tracing, security
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) in the linux kernel and several user space implementations of BPF
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) virtual machine led to a number of misunderstanding on what BPF actually is.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) This short QA is an attempt to address that and outline a direction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) of where BPF is heading long term.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) .. contents::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) :local:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) :depth: 3
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) Questions and Answers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) Q: Is BPF a generic instruction set similar to x64 and arm64?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) -------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) A: NO.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) Q: Is BPF a generic virtual machine ?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) -------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) A: NO.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) BPF is generic instruction set *with* C calling convention.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) -----------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) Q: Why C calling convention was chosen?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) A: Because BPF programs are designed to run in the linux kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) which is written in C, hence BPF defines instruction set compatible
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) with two most used architectures x64 and arm64 (and takes into
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) consideration important quirks of other architectures) and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) defines calling convention that is compatible with C calling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) convention of the linux kernel on those architectures.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) Q: Can multiple return values be supported in the future?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) A: NO. BPF allows only register R0 to be used as return value.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) Q: Can more than 5 function arguments be supported in the future?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) A: NO. BPF calling convention only allows registers R1-R5 to be used
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) as arguments. BPF is not a standalone instruction set.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) (unlike x64 ISA that allows msft, cdecl and other conventions)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) Q: Can BPF programs access instruction pointer or return address?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) -----------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) A: NO.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) Q: Can BPF programs access stack pointer ?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) ------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) A: NO.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) Only frame pointer (register R10) is accessible.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) From compiler point of view it's necessary to have stack pointer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) For example, LLVM defines register R11 as stack pointer in its
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) BPF backend, but it makes sure that generated code never uses it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) Q: Does C-calling convention diminishes possible use cases?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) -----------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) A: YES.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) BPF design forces addition of major functionality in the form
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) of kernel helper functions and kernel objects like BPF maps with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) seamless interoperability between them. It lets kernel call into
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) BPF programs and programs call kernel helpers with zero overhead,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) as all of them were native C code. That is particularly the case
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) for JITed BPF programs that are indistinguishable from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) native kernel C code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) Q: Does it mean that 'innovative' extensions to BPF code are disallowed?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) ------------------------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) A: Soft yes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) At least for now, until BPF core has support for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) bpf-to-bpf calls, indirect calls, loops, global variables,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) jump tables, read-only sections, and all other normal constructs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) that C code can produce.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) Q: Can loops be supported in a safe way?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) ----------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) A: It's not clear yet.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) BPF developers are trying to find a way to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) support bounded loops.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) Q: What are the verifier limits?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) --------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) A: The only limit known to the user space is BPF_MAXINSNS (4096).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) It's the maximum number of instructions that the unprivileged bpf
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) program can have. The verifier has various internal limits.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) Like the maximum number of instructions that can be explored during
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) program analysis. Currently, that limit is set to 1 million.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) Which essentially means that the largest program can consist
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) of 1 million NOP instructions. There is a limit to the maximum number
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) of subsequent branches, a limit to the number of nested bpf-to-bpf
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) calls, a limit to the number of the verifier states per instruction,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) a limit to the number of maps used by the program.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) All these limits can be hit with a sufficiently complex program.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) There are also non-numerical limits that can cause the program
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) to be rejected. The verifier used to recognize only pointer + constant
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) expressions. Now it can recognize pointer + bounded_register.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) bpf_lookup_map_elem(key) had a requirement that 'key' must be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) a pointer to the stack. Now, 'key' can be a pointer to map value.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) The verifier is steadily getting 'smarter'. The limits are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) being removed. The only way to know that the program is going to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) be accepted by the verifier is to try to load it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) The bpf development process guarantees that the future kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) versions will accept all bpf programs that were accepted by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) the earlier versions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) Instruction level questions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) ---------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) Q: LD_ABS and LD_IND instructions vs C code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) Q: How come LD_ABS and LD_IND instruction are present in BPF whereas
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) C code cannot express them and has to use builtin intrinsics?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) A: This is artifact of compatibility with classic BPF. Modern
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) networking code in BPF performs better without them.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) See 'direct packet access'.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) Q: BPF instructions mapping not one-to-one to native CPU
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) Q: It seems not all BPF instructions are one-to-one to native CPU.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) For example why BPF_JNE and other compare and jumps are not cpu-like?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) A: This was necessary to avoid introducing flags into ISA which are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) impossible to make generic and efficient across CPU architectures.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) Q: Why BPF_DIV instruction doesn't map to x64 div?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) A: Because if we picked one-to-one relationship to x64 it would have made
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) it more complicated to support on arm64 and other archs. Also it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) needs div-by-zero runtime check.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) Q: Why there is no BPF_SDIV for signed divide operation?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) A: Because it would be rarely used. llvm errors in such case and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) prints a suggestion to use unsigned divide instead.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) Q: Why BPF has implicit prologue and epilogue?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) A: Because architectures like sparc have register windows and in general
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) there are enough subtle differences between architectures, so naive
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) store return address into stack won't work. Another reason is BPF has
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) to be safe from division by zero (and legacy exception path
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) of LD_ABS insn). Those instructions need to invoke epilogue and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) return implicitly.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) Q: Why BPF_JLT and BPF_JLE instructions were not introduced in the beginning?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) A: Because classic BPF didn't have them and BPF authors felt that compiler
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) workaround would be acceptable. Turned out that programs lose performance
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) due to lack of these compare instructions and they were added.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) These two instructions is a perfect example what kind of new BPF
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) instructions are acceptable and can be added in the future.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) These two already had equivalent instructions in native CPUs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) New instructions that don't have one-to-one mapping to HW instructions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) will not be accepted.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) Q: BPF 32-bit subregister requirements
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) Q: BPF 32-bit subregisters have a requirement to zero upper 32-bits of BPF
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) registers which makes BPF inefficient virtual machine for 32-bit
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) CPU architectures and 32-bit HW accelerators. Can true 32-bit registers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) be added to BPF in the future?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) A: NO.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) But some optimizations on zero-ing the upper 32 bits for BPF registers are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) available, and can be leveraged to improve the performance of JITed BPF
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) programs for 32-bit architectures.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) Starting with version 7, LLVM is able to generate instructions that operate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) on 32-bit subregisters, provided the option -mattr=+alu32 is passed for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) compiling a program. Furthermore, the verifier can now mark the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) instructions for which zero-ing the upper bits of the destination register
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) is required, and insert an explicit zero-extension (zext) instruction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) (a mov32 variant). This means that for architectures without zext hardware
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) support, the JIT back-ends do not need to clear the upper bits for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) subregisters written by alu32 instructions or narrow loads. Instead, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) back-ends simply need to support code generation for that mov32 variant,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) and to overwrite bpf_jit_needs_zext() to make it return "true" (in order to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) enable zext insertion in the verifier).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) Note that it is possible for a JIT back-end to have partial hardware
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) support for zext. In that case, if verifier zext insertion is enabled,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) it could lead to the insertion of unnecessary zext instructions. Such
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) instructions could be removed by creating a simple peephole inside the JIT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) back-end: if one instruction has hardware support for zext and if the next
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) instruction is an explicit zext, then the latter can be skipped when doing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) the code generation.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) Q: Does BPF have a stable ABI?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) ------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) A: YES. BPF instructions, arguments to BPF programs, set of helper
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) functions and their arguments, recognized return codes are all part
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) of ABI. However there is one specific exception to tracing programs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) which are using helpers like bpf_probe_read() to walk kernel internal
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) data structures and compile with kernel internal headers. Both of these
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) kernel internals are subject to change and can break with newer kernels
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) such that the program needs to be adapted accordingly.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) Q: How much stack space a BPF program uses?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) -------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) A: Currently all program types are limited to 512 bytes of stack
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) space, but the verifier computes the actual amount of stack used
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) and both interpreter and most JITed code consume necessary amount.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) Q: Can BPF be offloaded to HW?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) ------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) A: YES. BPF HW offload is supported by NFP driver.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) Q: Does classic BPF interpreter still exist?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) --------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) A: NO. Classic BPF programs are converted into extend BPF instructions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) Q: Can BPF call arbitrary kernel functions?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) -------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) A: NO. BPF programs can only call a set of helper functions which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) is defined for every program type.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) Q: Can BPF overwrite arbitrary kernel memory?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) ---------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) A: NO.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) Tracing bpf programs can *read* arbitrary memory with bpf_probe_read()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) and bpf_probe_read_str() helpers. Networking programs cannot read
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) arbitrary memory, since they don't have access to these helpers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) Programs can never read or write arbitrary memory directly.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) Q: Can BPF overwrite arbitrary user memory?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) -------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) A: Sort-of.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) Tracing BPF programs can overwrite the user memory
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) of the current task with bpf_probe_write_user(). Every time such
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) program is loaded the kernel will print warning message, so
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) this helper is only useful for experiments and prototypes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) Tracing BPF programs are root only.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) Q: New functionality via kernel modules?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) ----------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) Q: Can BPF functionality such as new program or map types, new
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) helpers, etc be added out of kernel module code?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) A: NO.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags