diff options
| author | Alexei Starovoitov <ast@kernel.org> | 2019-04-17 21:27:01 -0400 |
|---|---|---|
| committer | Daniel Borkmann <daniel@iogearbox.net> | 2019-04-22 18:39:12 -0400 |
| commit | 3b8802446d27522cd6d32178ba975cc492611f31 (patch) | |
| tree | 13c3e3e2e01ef1aa55ba08d489383d337619806d | |
| parent | 4519efa6f8ea343e43ade21b0189b0b295439202 (diff) | |
bpf: document the verifier limits
Document the verifier limits.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
| -rw-r--r-- | Documentation/bpf/bpf_design_QA.rst | 29 |
1 files changed, 27 insertions, 2 deletions
diff --git a/Documentation/bpf/bpf_design_QA.rst b/Documentation/bpf/bpf_design_QA.rst index 10453c627135..cb402c59eca5 100644 --- a/Documentation/bpf/bpf_design_QA.rst +++ b/Documentation/bpf/bpf_design_QA.rst | |||
| @@ -85,8 +85,33 @@ Q: Can loops be supported in a safe way? | |||
| 85 | A: It's not clear yet. | 85 | A: It's not clear yet. |
| 86 | 86 | ||
| 87 | BPF developers are trying to find a way to | 87 | BPF developers are trying to find a way to |
| 88 | support bounded loops where the verifier can guarantee that | 88 | support bounded loops. |
| 89 | the program terminates in less than 4096 instructions. | 89 | |
| 90 | Q: What are the verifier limits? | ||
| 91 | -------------------------------- | ||
| 92 | A: The only limit known to the user space is BPF_MAXINSNS (4096). | ||
| 93 | It's the maximum number of instructions that the unprivileged bpf | ||
| 94 | program can have. The verifier has various internal limits. | ||
| 95 | Like the maximum number of instructions that can be explored during | ||
| 96 | program analysis. Currently, that limit is set to 1 million. | ||
| 97 | Which essentially means that the largest program can consist | ||
| 98 | of 1 million NOP instructions. There is a limit to the maximum number | ||
| 99 | of subsequent branches, a limit to the number of nested bpf-to-bpf | ||
| 100 | calls, a limit to the number of the verifier states per instruction, | ||
| 101 | a limit to the number of maps used by the program. | ||
| 102 | All these limits can be hit with a sufficiently complex program. | ||
| 103 | There are also non-numerical limits that can cause the program | ||
| 104 | to be rejected. The verifier used to recognize only pointer + constant | ||
| 105 | expressions. Now it can recognize pointer + bounded_register. | ||
| 106 | bpf_lookup_map_elem(key) had a requirement that 'key' must be | ||
| 107 | a pointer to the stack. Now, 'key' can be a pointer to map value. | ||
| 108 | The verifier is steadily getting 'smarter'. The limits are | ||
| 109 | being removed. The only way to know that the program is going to | ||
| 110 | be accepted by the verifier is to try to load it. | ||
| 111 | The bpf development process guarantees that the future kernel | ||
| 112 | versions will accept all bpf programs that were accepted by | ||
| 113 | the earlier versions. | ||
| 114 | |||
| 90 | 115 | ||
| 91 | Instruction level questions | 116 | Instruction level questions |
| 92 | --------------------------- | 117 | --------------------------- |
