check bpf_func_state->callback_depth when pruning states
Subsystems (4)
Eduard Zingerman
maintainerv3 cover check bpf_func_state->callback_depth when pruning states
This patch-set fixes bug in states pruning logic hit in mailing list discussion [0]. The details of the fix are in patch #1.
The main idea for the fix belongs to Yonghong Song, mine contribution is merely in review and test cases.
There are some changes in verification performance:
File Program Insns (DIFF) States (DIFF) ------------------------- ------------- --------------- -------------- pyperf600_bpf_loop.bpf.o on_event +15 (+0.42%) +0 (+0.00%) strobemeta_bpf_loop.bpf.o on_event +857 (+37.95%) +60 (+38.96%) xdp_synproxy_kern.bpf.o syncookie_tc +2892 (+30.39%) +109 (+36.33%) xdp_synproxy_kern.bpf.o syncookie_xdp +2892 (+30.01%) +109 (+36.09%)
(when tested on a subset of selftests identified by
selftests/bpf/veristat.cfg and Cilium bpf object files from [4])
Changelog:
v2 [2] -> v3:
- fixes for verifier.c commit message as suggested by Yonghong;
- patch-set re-rerouted to 'bpf' tree as suggested in [2];
- patch for test_tcp_custom_syncookie is sent separately to 'bpf-next' [3].
- veristat results updated using 'bpf' tree as baseline and clang 16.
v1 [1] -> v2:
- patch #2 commit message updated to better reflect verifier behavior with regards to checkpoints tree (suggested by Yonghong);
- veristat results added (suggested by Andrii).
[0] https://lore.kernel.org/bpf/[email protected]/
[1] https://lore.kernel.org/bpf/[email protected]/
[2] https://lore.kernel.org/bpf/[email protected]/
[3] https://lore.kernel.org/bpf/[email protected]/
[4] https://github.com/anakryiko/cilium
Eduard Zingerman (2):
bpf: check bpf_func_state->callback_depth when pruning states selftests/bpf: test case for callback_depth states pruning logic
kernel/bpf/verifier.c | 3 + .../bpf/progs/verifier_iterating_callbacks.c | 70 +++++++++++++++++++ 2 files changed, 73 insertions(+)
Signature · 1 line
2.43.0
Eduard Zingerman
maintainerPATCH v3 1/2 bpf: check bpf_func_state->callback_depth when pruning states
When comparing current and cached states verifier should consider bpf_func_state->callback_depth. Current state cannot be pruned against cached state, when current states has more iterations left compared to cached state. Current state has more iterations left when it's callback_depth is smaller.
Below is an example illustrating this bug, minimized from mailing list discussion [0] (assume that BPF_F_TEST_STATE_FREQ is set). The example is not a safe program: if loop_cb point (1) is followed by loop_cb point (2), then division by zero is possible at point (4).
struct ctx {
__u64 a;
__u64 b;
__u64 c;
};
static void loop_cb(int i, struct ctx *ctx)
{
/* assume that generated code is "fallthrough-first":
* if ... == 1 goto
* if ... == 2 goto
* <default>
*/
switch (bpf_get_prandom_u32()) {
case 1: /* 1 */ ctx->a = 42; return 0; break;
case 2: /* 2 */ ctx->b = 42; return 0; break;
default: /* 3 */ ctx->c = 42; return 0; break;
}
}
SEC("tc")
__failure
__flag(BPF_F_TEST_STATE_FREQ)
int test(struct __sk_buff *skb)
{
struct ctx ctx = { 7, 7, 7 };
bpf_loop(2, loop_cb, &ctx, 0); /* 0 */
/* assume generated checks are in-order: .a first */
if (ctx.a == 42 && ctx.b == 42 && ctx.c == 7)
asm volatile("r0 /= 0;":::"r0"); /* 4 */
return 0;
}Prior to this commit verifier built the following checkpoint tree for this example:
.------------------------------------- Checkpoint / State name
| .-------------------------------- Code point number
| | .---------------------------- Stack state {ctx.a,ctx.b,ctx.c}
| | | .------------------- Callback depth in frame #0
v v v v - (0) {7P,7P,7},depth=0
- (3) {7P,7P,7},depth=1
- (0) {7P,7P,42},depth=1
- (3) {7P,7,42},depth=2
- (0) {7P,7,42},depth=2 loop terminates because of depth limit
- (4) {7P,7,42},depth=0 predicted false, ctx.a marked precise
- (6) exit
(a) - (2) {7P,7,42},depth=2
- (0) {7P,42,42},depth=2 loop terminates because of depth limit
- (4) {7P,42,42},depth=0 predicted false, ctx.a marked precise
- (6) exit
(b) - (1) {7P,7P,42},depth=2
- (0) {42P,7P,42},depth=2 loop terminates because of depth limit
- (4) {42P,7P,42},depth=0 predicted false, ctx.{a,b} marked precise
- (6) exit
- (2) {7P,7,7},depth=1 considered safe, pruned using checkpoint (a)
(c) - (1) {7P,7P,7},depth=1 considered safe, pruned using checkpoint (b)
Here checkpoint (b) has callback_depth of 2, meaning that it would never reach state {42,42,7}.
While checkpoint (c) has callback_depth of 1, and thus could yet explore the state {42,42,7} if not pruned prematurely. This commit makes forbids such premature pruning, allowing verifier to explore states sub-tree starting at (c):
(c) - (1) {7,7,7P},depth=1
- (0) {42P,7,7P},depth=1
...
- (2) {42,7,7},depth=2
- (0) {42,42,7},depth=2 loop terminates because of depth limit
- (4) {42,42,7},depth=0 predicted true, ctx.{a,b,c} marked precise
- (5) division by zero
[0] https://lore.kernel.org/bpf/[email protected]/
--- kernel/bpf/verifier.c | 3 +++ 1 file changed, 3 insertions(+)
kernel/bpf/verifier.c +3 -0
@@ -16602,6 +16602,9 @@ static bool func_states_equal(struct bpf_verifier_env *env, struct bpf_func_stat {int i; +if (old->callback_depth > cur->callback_depth) +return false; +for (i =0 ; i <MAX_BPF_REG ; i++)if (!regsafe (env, &old->regs[i], &cur->regs[i], &env->idmap_scratch, exact))
Signature · 1 line
2.43.0
Re: [PATCH bpf v3 1/2] bpf: check bpf_func_state->callback_depth when pruning states
Quoted 86 lines · Eduard Zingerman
When comparing current and cached states verifier should consider
bpf_func_state->callback_depth. Current state cannot be pruned against cached state, when current states has more iterations left compared to cached state. Current state has more iterations left when it'scallback_depthis smaller.Below is an example illustrating this bug, minimized from mailing list discussion [0] (assume that
BPF_F_TEST_STATE_FREQis set). The example is not a safe program: ifloop_cbpoint (1) is followed byloop_cbpoint (2), then division by zero is possible at point (4).struct ctx { __u64 a; __u64 b; __u64 c; }; static void loop_cb(int i, struct ctx *ctx) { /* assume that generated code is "fallthrough-first": * if ... == 1 goto * if ... == 2 goto * <default> */ switch (bpf_get_prandom_u32()) { case 1: /* 1 */ ctx->a = 42; return 0; break; case 2: /* 2 */ ctx->b = 42; return 0; break; default: /* 3 */ ctx->c = 42; return 0; break; } } SEC("tc") __failure __flag(BPF_F_TEST_STATE_FREQ) int test(struct __sk_buff *skb) { struct ctx ctx = { 7, 7, 7 }; bpf_loop(2, loop_cb, &ctx, 0); /* 0 */ /* assume generated checks are in-order: .a first */ if (ctx.a == 42 && ctx.b == 42 && ctx.c == 7) asm volatile("r0 /= 0;":::"r0"); /* 4 */ return 0; }Prior to this commit verifier built the following checkpoint tree for this example:
.------------------------------------- Checkpoint / State name
| .-------------------------------- Code point number | | .---------------------------- Stack state {ctx.a,ctx.b,ctx.c} | | | .------------------- Callback depth in frame #0 v v v v- (0) {7P,7P,7},depth=0
- (3) {7P,7P,7},depth=1
- (0) {7P,7P,42},depth=1
- (3) {7P,7,42},depth=2
- (0) {7P,7,42},depth=2 loop terminates because of depth limit
- (4) {7P,7,42},depth=0 predicted false, ctx.a marked precise
- (6) exit
(a) - (2) {7P,7,42},depth=2
- (0) {7P,42,42},depth=2 loop terminates because of depth limit
- (4) {7P,42,42},depth=0 predicted false, ctx.a marked precise
- (6) exit
(b) - (1) {7P,7P,42},depth=2
- (0) {42P,7P,42},depth=2 loop terminates because of depth limit
- (4) {42P,7P,42},depth=0 predicted false, ctx.{a,b} marked precise
- (6) exit
- (2) {7P,7,7},depth=1 considered safe, pruned using checkpoint (a)
(c) - (1) {7P,7P,7},depth=1 considered safe, pruned using checkpoint (b)Here checkpoint (b) has
callback_depthof 2, meaning that it would never reach state {42,42,7}.
While checkpoint (c) hascallback_depthof 1, and thus could yet explore the state {42,42,7} if not pruned prematurely. This commit makes forbids such premature pruning, allowing verifier to explore states sub-tree starting at (c):(c) - (1) {7,7,7P},depth=1
- (0) {42P,7,7P},depth=1
...
- (2) {42,7,7},depth=2
- (0) {42,42,7},depth=2 loop terminates because of depth limit
- (4) {42,42,7},depth=0 predicted true, ctx.{a,b,c} marked precise
- (5) division by zero
Quoted 5 lines
[0] https://lore.kernel.org/bpf/[email protected]/
Fixes bb124da69c47 ("bpf: keep track of max number of bpf_loop callback iterations")Suggested-by Yonghong Song <[email protected]>Signed-off-by Eduard Zingerman <[email protected]>
Thanks for updating commit messages. It looks correct to me.
Eduard Zingerman
maintainerPATCH v3 2/2 selftests/bpf: test case for callback_depth states pruning logic
In reply to Eduard ZingermanThe test case was minimized from mailing list discussion [0]. It is equivalent to the following C program:
struct iter_limit_bug_ctx { __u64 a; __u64 b; __u64 c; };
static __naked void iter_limit_bug_cb(void)
{
switch (bpf_get_prandom_u32()) {
case 1: ctx->a = 42; break;
case 2: ctx->b = 42; break;
default: ctx->c = 42; break;
}
}
int iter_limit_bug(struct __sk_buff *skb)
{
struct iter_limit_bug_ctx ctx = { 7, 7, 7 };
bpf_loop(2, iter_limit_bug_cb, &ctx, 0);
if (ctx.a == 42 && ctx.b == 42 && ctx.c == 7)
asm volatile("r1 /= 0;":::"r1");
return 0;
}The main idea is that each loop iteration changes one of the state variables in a non-deterministic manner. Hence it is premature to prune the states that have two iterations left comparing them to states with one iteration left.
E.g. {{7,7,7}, callback_depth=0} can reach state {42,42,7}, while {{7,7,7}, callback_depth=1} can't.
[0] https://lore.kernel.org/bpf/[email protected]/
--- .../bpf/progs/verifier_iterating_callbacks.c | 70 +++++++++++++++++++ 1 file changed, 70 insertions(+)
tools/testing/selftests/bpf/progs/verifier_iterating_callbacks.c +70 -0
@@ -239,4 +239,74 @@ int bpf_loop_iter_limit_nested(void *unused)return 1000 * a + b + c; } +struct iter_limit_bug_ctx { +__u64 a; +__u64 b; +__u64 c; +}; + +static __naked void iter_limit_bug_cb (void ) +{ +/* This is the same as C code below, but written +* in assembly to control which branches are fall-through. +* +* switch (bpf_get_prandom_u32()) { +* case 1: ctx->a = 42; break; +* case 2: ctx->b = 42; break; +* default: ctx->c = 42; break; +* } +*/ + asmvolatile ( +"r9 = r2;" +"call %[bpf_get_prandom_u32];" +"r1 = r0;" +"r2 = 42;" +"r0 = 0;" +"if r1 == 0x1 goto 1f;" +"if r1 == 0x2 goto 2f;" +"*(u64 *)(r9 + 16) = r2;" +"exit;" +"1: *(u64 *)(r9 + 0) = r2;" +"exit;" +"2: *(u64 *)(r9 + 8) = r2;" +"exit;" + : + : __imm(bpf_get_prandom_u32) + : __clobber_all + ); +} + +SEC("tc") +__failure +__flag(BPF_F_TEST_STATE_FREQ) +int iter_limit_bug(struct __sk_buff *skb) +{ + struct iter_limit_bug_ctx ctx = { 7, 7, 7 }; + + bpf_loop(2, iter_limit_bug_cb, &ctx, 0); + + /* This is the same as C code below, + * written in assembly to guarantee checks order. + * + * if (ctx.a == 42 && ctx.b == 42 && ctx.c == 7) + * asm volatile("r1 /= 0;":::"r1"); + */ + asm volatile ( +"r1 = *(u64 *)%[ctx_a];" +"if r1 != 42 goto 1f;" +"r1 = *(u64 *)%[ctx_b];" +"if r1 != 42 goto 1f;" +"r1 = *(u64 *)%[ctx_c];" +"if r1 != 7 goto 1f;" +"r1 /= 0;" +"1:" + : + : [ctx_a]"m"(ctx.a), + [ctx_b]"m"(ctx.b), + [ctx_c]"m"(ctx.c) + : "r1" + ); +return 0 ; +} + char _license[] SEC("license") = "GPL";
Signature · 1 line
2.43.0
This series was applied to bpf/bpf.git (master) by Alexei Starovoitov <[email protected]>:
Hello:
This series was applied to bpf/bpf.git (master)
by Alexei Starovoitov <[email protected]>:
Quoted 9 lines · On Thu, 22 Feb 2024 17:41:19 +0200 you wrote:
This patch-set fixes bug in states pruning logic hit in mailing list discussion [0]. The details of the fix are in patch #1.
The main idea for the fix belongs to Yonghong Song, mine contribution is merely in review and test cases.
There are some changes in verification performance:
[...]
Here is the summary with links:
- [bpf,v3,1/2] bpf: check bpf_func_state->callback_depth when pruning states
https://git.kernel.org/bpf/bpf/c/f31f0fe3d738 - [bpf,v3,2/2] selftests/bpf: test case for callback_depth states pruning logic https://git.kernel.org/bpf/bpf/c/2861d07c5289
You are awesome, thank you!
Signature · 2 lines
Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html