Alexei Starovoitov | 51580e7 | 2014-09-26 00:17:02 -0700 | [diff] [blame^] | 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 | } |