]>
Commit | Line | Data |
---|---|---|
51580e79 AS |
1 | /* Copyright (c) 2011-2014 PLUMgrid, http://plumgrid.com |
2 | * | |
3 | * This program is free software; you can redistribute it and/or | |
4 | * modify it under the terms of version 2 of the GNU General Public | |
5 | * License as published by the Free Software Foundation. | |
6 | * | |
7 | * This program is distributed in the hope that it will be useful, but | |
8 | * WITHOUT ANY WARRANTY; without even the implied warranty of | |
9 | * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | |
10 | * General Public License for more details. | |
11 | */ | |
12 | #include <linux/kernel.h> | |
13 | #include <linux/types.h> | |
14 | #include <linux/slab.h> | |
15 | #include <linux/bpf.h> | |
16 | #include <linux/filter.h> | |
17 | #include <net/netlink.h> | |
18 | #include <linux/file.h> | |
19 | #include <linux/vmalloc.h> | |
20 | ||
21 | /* bpf_check() is a static code analyzer that walks eBPF program | |
22 | * instruction by instruction and updates register/stack state. | |
23 | * All paths of conditional branches are analyzed until 'bpf_exit' insn. | |
24 | * | |
25 | * The first pass is depth-first-search to check that the program is a DAG. | |
26 | * It rejects the following programs: | |
27 | * - larger than BPF_MAXINSNS insns | |
28 | * - if loop is present (detected via back-edge) | |
29 | * - unreachable insns exist (shouldn't be a forest. program = one function) | |
30 | * - out of bounds or malformed jumps | |
31 | * The second pass is all possible path descent from the 1st insn. | |
32 | * Since it's analyzing all pathes through the program, the length of the | |
33 | * analysis is limited to 32k insn, which may be hit even if total number of | |
34 | * insn is less then 4K, but there are too many branches that change stack/regs. | |
35 | * Number of 'branches to be analyzed' is limited to 1k | |
36 | * | |
37 | * On entry to each instruction, each register has a type, and the instruction | |
38 | * changes the types of the registers depending on instruction semantics. | |
39 | * If instruction is BPF_MOV64_REG(BPF_REG_1, BPF_REG_5), then type of R5 is | |
40 | * copied to R1. | |
41 | * | |
42 | * All registers are 64-bit. | |
43 | * R0 - return register | |
44 | * R1-R5 argument passing registers | |
45 | * R6-R9 callee saved registers | |
46 | * R10 - frame pointer read-only | |
47 | * | |
48 | * At the start of BPF program the register R1 contains a pointer to bpf_context | |
49 | * and has type PTR_TO_CTX. | |
50 | * | |
51 | * Verifier tracks arithmetic operations on pointers in case: | |
52 | * BPF_MOV64_REG(BPF_REG_1, BPF_REG_10), | |
53 | * BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, -20), | |
54 | * 1st insn copies R10 (which has FRAME_PTR) type into R1 | |
55 | * and 2nd arithmetic instruction is pattern matched to recognize | |
56 | * that it wants to construct a pointer to some element within stack. | |
57 | * So after 2nd insn, the register R1 has type PTR_TO_STACK | |
58 | * (and -20 constant is saved for further stack bounds checking). | |
59 | * Meaning that this reg is a pointer to stack plus known immediate constant. | |
60 | * | |
61 | * Most of the time the registers have UNKNOWN_VALUE type, which | |
62 | * means the register has some value, but it's not a valid pointer. | |
63 | * (like pointer plus pointer becomes UNKNOWN_VALUE type) | |
64 | * | |
65 | * When verifier sees load or store instructions the type of base register | |
66 | * can be: PTR_TO_MAP_VALUE, PTR_TO_CTX, FRAME_PTR. These are three pointer | |
67 | * types recognized by check_mem_access() function. | |
68 | * | |
69 | * PTR_TO_MAP_VALUE means that this register is pointing to 'map element value' | |
70 | * and the range of [ptr, ptr + map's value_size) is accessible. | |
71 | * | |
72 | * registers used to pass values to function calls are checked against | |
73 | * function argument constraints. | |
74 | * | |
75 | * ARG_PTR_TO_MAP_KEY is one of such argument constraints. | |
76 | * It means that the register type passed to this function must be | |
77 | * PTR_TO_STACK and it will be used inside the function as | |
78 | * 'pointer to map element key' | |
79 | * | |
80 | * For example the argument constraints for bpf_map_lookup_elem(): | |
81 | * .ret_type = RET_PTR_TO_MAP_VALUE_OR_NULL, | |
82 | * .arg1_type = ARG_CONST_MAP_PTR, | |
83 | * .arg2_type = ARG_PTR_TO_MAP_KEY, | |
84 | * | |
85 | * ret_type says that this function returns 'pointer to map elem value or null' | |
86 | * function expects 1st argument to be a const pointer to 'struct bpf_map' and | |
87 | * 2nd argument should be a pointer to stack, which will be used inside | |
88 | * the helper function as a pointer to map element key. | |
89 | * | |
90 | * On the kernel side the helper function looks like: | |
91 | * u64 bpf_map_lookup_elem(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5) | |
92 | * { | |
93 | * struct bpf_map *map = (struct bpf_map *) (unsigned long) r1; | |
94 | * void *key = (void *) (unsigned long) r2; | |
95 | * void *value; | |
96 | * | |
97 | * here kernel can access 'key' and 'map' pointers safely, knowing that | |
98 | * [key, key + map->key_size) bytes are valid and were initialized on | |
99 | * the stack of eBPF program. | |
100 | * } | |
101 | * | |
102 | * Corresponding eBPF program may look like: | |
103 | * BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), // after this insn R2 type is FRAME_PTR | |
104 | * BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -4), // after this insn R2 type is PTR_TO_STACK | |
105 | * BPF_LD_MAP_FD(BPF_REG_1, map_fd), // after this insn R1 type is CONST_PTR_TO_MAP | |
106 | * BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem), | |
107 | * here verifier looks at prototype of map_lookup_elem() and sees: | |
108 | * .arg1_type == ARG_CONST_MAP_PTR and R1->type == CONST_PTR_TO_MAP, which is ok, | |
109 | * Now verifier knows that this map has key of R1->map_ptr->key_size bytes | |
110 | * | |
111 | * Then .arg2_type == ARG_PTR_TO_MAP_KEY and R2->type == PTR_TO_STACK, ok so far, | |
112 | * Now verifier checks that [R2, R2 + map's key_size) are within stack limits | |
113 | * and were initialized prior to this call. | |
114 | * If it's ok, then verifier allows this BPF_CALL insn and looks at | |
115 | * .ret_type which is RET_PTR_TO_MAP_VALUE_OR_NULL, so it sets | |
116 | * R0->type = PTR_TO_MAP_VALUE_OR_NULL which means bpf_map_lookup_elem() function | |
117 | * returns ether pointer to map value or NULL. | |
118 | * | |
119 | * When type PTR_TO_MAP_VALUE_OR_NULL passes through 'if (reg != 0) goto +off' | |
120 | * insn, the register holding that pointer in the true branch changes state to | |
121 | * PTR_TO_MAP_VALUE and the same register changes state to CONST_IMM in the false | |
122 | * branch. See check_cond_jmp_op(). | |
123 | * | |
124 | * After the call R0 is set to return type of the function and registers R1-R5 | |
125 | * are set to NOT_INIT to indicate that they are no longer readable. | |
126 | */ | |
127 | ||
128 | int bpf_check(struct bpf_prog *prog, union bpf_attr *attr) | |
129 | { | |
130 | int ret = -EINVAL; | |
131 | ||
132 | return ret; | |
133 | } |