Lines Matching +full:a +full:- +full:8
16 At the start of the program the register R1 contains a pointer to context
32 After kernel function call, R1-R5 are reset to unreadable and
33 R0 has a return type of the function.
35 Since R6-R9 are callee saved, their state is preserved across the call.
44 is a correct program. If there was R1 instead of R6, it would have
56 will be rejected, since R1 doesn't have a valid pointer type at the time of
59 At the start R1 type is PTR_TO_CTX (a pointer to generic ``struct bpf_context``)
60 A callback is used to customize verifier to restrict eBPF program access to only
65 bpf_ld R0 = *(u32 *)(R6 + 8)
67 intends to load a word from address R6 + 8 and store it into R0
69 that offset 8 of size 4 bytes can be accessed for reading, otherwise
72 stack bounds, which are [-MAX_BPF_STACK, 0). In this example offset is 8,
78 Classic BPF verifier does similar check with M[0-15] memory slots.
81 bpf_ld R0 = *(u32 *)(R10 - 4)
85 Though R10 is correct read-only register and has type PTR_TO_STACK
86 and R10 - 4 is within stack bounds, there were no stores into that location.
88 Pointer register spill/fill is tracked as well, since four (R6-R9)
91 Allowed function calls are customized with bpf_verifier_ops->get_func_proto()
95 Function calls is a main mechanism to extend functionality of eBPF programs.
99 If a function made accessible to eBPF program, it needs to be thought through
117 register state has a type, which is either NOT_INIT (the register has not been
118 written to), SCALAR_VALUE (some value which is not usable as a pointer), or a
128 Pointer to the value stored in a map element.
130 Either a pointer to a map value, or NULL; map accesses
131 (see maps.rst) return this type, which becomes a
137 skb->data.
139 skb->data + headlen; arithmetic forbidden.
143 Either a pointer to a socket, or NULL; socket lookup
144 returns this type, which becomes a PTR_TO_SOCKET when
145 checked != NULL. PTR_TO_SOCKET is reference-counted,
150 However, a pointer may be offset from this base (as a result of pointer
152 offset'. The former is used when an exactly-known value (e.g. an immediate
153 operand) is added to a pointer, while the latter is used for values which are
162 * knowledge of the values of individual bits, in the form of a 'tnum': a u64
163 'mask' and a u64 'value'. 1s in the mask represent bits whose value is unknown;
165 mask and value; no bit should ever be 1 in both. For example, if a byte is read
166 into a register from memory, the register's top 56 bits are known zero, while
167 the low 8 are unknown - which is represented as the tnum (0x0; 0xff). If we
172 branches. For instance, if a SCALAR_VALUE is compared > 8, in the 'true' branch
173 it will have a umin_value (unsigned minimum value) of 9, whereas in the 'false'
174 branch it will have a umax_value of 8. A signed compare (with BPF_JSGT or
176 from the signed and unsigned bounds can be combined; for instance if a value is
177 first tested < 8 and then tested s> 4, the verifier will conclude that the value
178 is also > 4 and s< 8, since the bounds prevent crossing the sign boundary.
180 PTR_TO_PACKETs with a variable offset part have an 'id', which is common to all
182 checks: after adding a variable to a packet pointer register A, if you then copy
183 it to another register B and then add a constant 4 to A, both registers will
184 share the same 'id' but the A will have a fixed offset of +4. Then if A is
185 bounds-checked and found to be less than a PTR_TO_PACKET_END, the register B is
186 now known to have a safe range of at least 4 bytes. See 'Direct packet access',
190 the pointer returned from a map lookup. This means that when one copy is
191 checked and found to be non-NULL, all copies can become PTR_TO_MAP_VALUEs.
192 As well as range-checking, the tracked information is also used for enforcing
194 is 2 bytes after a 4-byte alignment. If a program adds 14 bytes to that to jump
196 pointer will have a variable offset known to be 4n+2 for some n, so adding the 2
197 bytes (NET_IP_ALIGN) gives a 4-byte alignment and so word-sized accesses through
200 to all copies of the pointer returned from a socket lookup. This has similar
201 behaviour to the handling for PTR_TO_MAP_VALUE_OR_NULL->PTR_TO_MAP_VALUE, but
203 represents a reference to the corresponding ``struct sock``. To ensure that the
204 reference is not leaked, it is imperative to NULL-check the reference and in
205 the non-NULL case, and pass the valid reference to the socket release function.
211 data via skb->data and skb->data_end pointers.
214 1: r4 = *(u32 *)(r1 +80) /* load skb->data_end */
215 2: r3 = *(u32 *)(r1 +76) /* load skb->data */
223 did check ``if (skb->data + 14 > skb->data_end) goto err`` at insn #5 which
224 means that in the fall-through case the register R3 (which points to skb->data)
232 it now points to ``skb->data + 14`` and accessible range is [R5, R5 + 14 - 14)
241 8: r4 *= 14
242 9: r3 = *(u32 *)(r1 +76) /* load skb->data */
249 16: r2 += 8
250 17: r1 = *(u32 *)(r1 +80) /* load skb->data_end */
252 …max_value=255,var_off=(0x0; 0xff)) R1=pkt_end R2=pkt(id=2,off=8,r=8) R3=pkt(id=2,off=0,r=8) R4=inv…
255 The state of the register R3 is R3=pkt(id=2,off=0,r=8)
257 offset within a packet and since the program author did
258 ``if (r3 + 8 > r1) goto err`` at insn #18, the safe range is [R3, R3 + 8).
263 Operation ``r3 += rX`` may overflow and become less than original skb->data,
265 instruction and rX is more than 16-bit value, any subsequent bounds-check of r3
266 against skb->data_end will not give us 'range' information, so attempts to read
272 8 bits. After insn ``r4 *= 14`` the state becomes
273 R4=inv(id=0,umax_value=3570,var_off=(0x0; 0xfffe)), since multiplying an 8-bit
284 void *data = (void *)(long)skb->data;
285 void *data_end = (void *)(long)skb->data_end;
292 if (eth->h_proto != htons(ETH_P_IP))
294 if (iph->protocol != IPPROTO_UDP || iph->ihl != 5)
296 if (udp->dest == 53 || udp->source == 9)
307 been in when at this instruction. If any of them contain the current state as a
308 subset, the branch is 'pruned' - that is, the fact that the previous state was
310 previous state, r1 held a packet-pointer, and in the current state, r1 holds a
311 packet-pointer with a range as long or longer and at least as strict an
322 --------------------------
328 removed from the cached state thus making more states equivalent to a cached
335 --- checkpoint ---
339 Suppose that a state cache entry is created at instruction #4 (such entries are
389 * ``REG_LIVE_NONE`` is an initial value assigned to ``->live`` fields upon new
397 is read by a some child state of this verifier state;
399 * ``REG_LIVE_DONE`` is a marker used by ``clean_verifier_state()`` to avoid
402 * ``->live`` field values are formed by combining ``enum bpf_reg_liveness``
408 In order to propagate information between parent and child states, a *register
409 parentage chain* is established. Each register or stack slot is linked to a
410 corresponding register or stack slot in its parent state via a ``->parent``
421 * For the outer stack frames, only caller saved registers (r6-r9) and stack
425 * When function call is processed a new ``struct bpf_func_state`` instance is
426 allocated, it encapsulates a new set of registers and stack slots. For this
427 new frame, parent links for r6-r9 and stack slots are set to nil, parent links
428 for r1-r5 are set to match caller r1-r5 parent links.
431 ``->parent`` pointers)::
434 --- checkpoint #0 ---
436 --- checkpoint #1 ---
439 --- checkpoint #2 ---
441 --- checkpoint #3 ---
443 3 : r1 = r6 ; Frame #0 <- current state
445 +-------------------------------+-------------------------------+
447 Checkpoint +-------------------------------+-------------------------------+
448 #0 | r0 | r1-r5 | r6-r9 | fp-8 ... |
449 +-------------------------------+
452 Checkpoint +-------------------------------+
453 #1 | r0 | r1-r5 | r6-r9 | fp-8 ... |
454 +-------------------------------+
460 Checkpoint +-------------------------------+-------------------------------+
461 #2 | r0 | r1-r5 | r6-r9 | fp-8 ... | r0 | r1-r5 | r6-r9 | fp-8 ... |
462 +-------------------------------+-------------------------------+
466 Checkpoint +-------------------------------+-------------------------------+
467 #3 | r0 | r1-r5 | r6-r9 | fp-8 ... | r0 | r1-r5 | r6-r9 | fp-8 ... |
468 +-------------------------------+-------------------------------+
472 Current +-------------------------------+
473 state | r0 | r1-r5 | r6-r9 | fp-8 ... |
474 +-------------------------------+
478 The checkpoint #1 contains a write mark for r6
487 back along the state parentage chain until they hit a write mark, which 'screens
492 parent = state->parent
494 if state->live & REG_LIVE_WRITTEN:
496 if parent->live & REG_LIVE_READ64:
498 parent->live |= REG_LIVE_READ64
500 parent = state->parent
505 applied to the **current** state. The write mark on a register or stack slot
506 means that it is updated by some instruction in the straight-line code leading
522 0: (*u64)(r10 - 8) = 0 ; define 8 bytes of fp-8
523 --- checkpoint #0 ---
524 1: (*u32)(r10 - 8) = 1 ; redefine lower 4 bytes
525 2: r1 = (*u32)(r10 - 8) ; read lower 4 bytes defined at (1)
526 3: r2 = (*u32)(r10 - 4) ; read upper 4 bytes defined at (0)
533 called to update the ``->branches`` counter for each verifier state in a chain
534 of parent verifier states. When the ``->branches`` counter reaches zero the
535 verifier state becomes a valid entry in a set of cached verifier states.
537 Each entry of the verifier states cache is post-processed by a function
541 called from ``states_equal()`` when a state cache entry is considered for
542 equivalence with a current state.
551 --- checkpoint[0] ---
565 by ``clean_live_states()``. After this processing ``checkpoint[0].r0`` has a
570 and is compared against a cached state ``{ r1 == 0, pc == 4 }``, the states
578 Another point is the handling of read marks when a previously verified state is
585 Consider the following state parentage chain (S is a starting state, A-E are
586 derived states, -> arrows show which state is derived from which)::
589 <------------- A[r1] == 0
591 S ---> A ---> B ---> exit E[r1] == 1
593 ` ---> C ---> D
595 ` ---> E ^
602 * Chain of states ``S -> A -> B -> exit`` is verified first.
604 * While ``B -> exit`` is verified, register ``r1`` is read and this read mark is
605 propagated up to state ``A``.
607 * When chain of states ``C -> D`` is verified the state ``D`` turns out to be
654 BPF_ST_MEM(BPF_DW, BPF_REG_10, 8, 0),
659 0: (7a) *(u64 *)(r10 +8) = 0
660 invalid stack off=8 size=8
665 BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
673 1: (07) r2 += -8
676 invalid indirect read from stack off -8+0 size 8
680 BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
682 BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
689 0: (7a) *(u64 *)(r10 -8) = 0
691 2: (07) r2 += -8
699 BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
701 BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
709 0: (7a) *(u64 *)(r10 -8) = 0
711 2: (07) r2 += -8
714 5: (7a) *(u64 *)(r0 +0) = 0
720 BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
722 BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
731 0: (7a) *(u64 *)(r10 -8) = 0
733 2: (07) r2 += -8
738 6: (7a) *(u64 *)(r0 +4) = 0
739 misaligned access off 4 size 8
745 BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
747 BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
758 0: (7a) *(u64 *)(r10 -8) = 0
760 2: (07) r2 += -8
765 6: (7a) *(u64 *)(r0 +0) = 0
768 from 5 to 8: R0=imm0 R10=fp
769 8: (7a) *(u64 *)(r0 +0) = 1
772 Program that performs a socket lookup then sets the pointer to NULL without
776 BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_2, -8),
778 BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
789 1: (63) *(u32 *)(r10 -8) = r2
791 3: (07) r2 += -8
796 8: (b7) r0 = 0
800 Program that performs a socket lookup but does not NULL-check the returned
804 BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_2, -8),
806 BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
816 1: (63) *(u32 *)(r10 -8) = r2
818 3: (07) r2 += -8
823 8: (95) exit