* [PATCH] bpf: Refactor ptr alu checking rules to allow alu explicitly
@ 2024-01-17 9:40 Hao Sun
2024-01-17 9:42 ` Hao Sun
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Hao Sun @ 2024-01-17 9:40 UTC (permalink / raw)
To: bpf; +Cc: ast, andrii, daniel, eddyz87, linux-kernel, Hao Sun
Current checking rules are structured to disallow alu on particular ptr
types explicitly, so default cases are allowed implicitly. This may lead
to newly added ptr types being allowed unexpectedly. So restruture it to
allow alu explicitly. The tradeoff is mainly a bit more cases added in
the switch. The following table from Eduard summarizes the rules:
| Pointer type | Arithmetics allowed |
|---------------------+---------------------|
| PTR_TO_CTX | yes |
| CONST_PTR_TO_MAP | conditionally |
| PTR_TO_MAP_VALUE | yes |
| PTR_TO_MAP_KEY | yes |
| PTR_TO_STACK | yes |
| PTR_TO_PACKET_META | yes |
| PTR_TO_PACKET | yes |
| PTR_TO_PACKET_END | no |
| PTR_TO_FLOW_KEYS | conditionally |
| PTR_TO_SOCKET | no |
| PTR_TO_SOCK_COMMON | no |
| PTR_TO_TCP_SOCK | no |
| PTR_TO_TP_BUFFER | yes |
| PTR_TO_XDP_SOCK | no |
| PTR_TO_BTF_ID | yes |
| PTR_TO_MEM | yes |
| PTR_TO_BUF | yes |
| PTR_TO_FUNC | yes |
| CONST_PTR_TO_DYNPTR | yes |
The refactored rules are equivalent to the original one. Note that
PTR_TO_FUNC and CONST_PTR_TO_DYNPTR are not reject here because: (1)
check_mem_access() rejects load/store on those ptrs, and those ptrs
with offset passing to calls are rejected check_func_arg_reg_off();
(2) someone may rely on the verifier not rejecting programs earily.
Signed-off-by: Hao Sun <sunhao.th@gmail.com>
---
kernel/bpf/verifier.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 65f598694d55..861d8d824bb8 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -12826,6 +12826,19 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env,
}
switch (base_type(ptr_reg->type)) {
+ case PTR_TO_CTX:
+ case PTR_TO_MAP_VALUE:
+ case PTR_TO_MAP_KEY:
+ case PTR_TO_STACK:
+ case PTR_TO_PACKET_META:
+ case PTR_TO_PACKET:
+ case PTR_TO_TP_BUFFER:
+ case PTR_TO_BTF_ID:
+ case PTR_TO_MEM:
+ case PTR_TO_BUF:
+ case PTR_TO_FUNC:
+ case CONST_PTR_TO_DYNPTR:
+ break;
case PTR_TO_FLOW_KEYS:
if (known)
break;
@@ -12835,16 +12848,10 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env,
if (known && smin_val == 0 && opcode == BPF_ADD)
break;
fallthrough;
- case PTR_TO_PACKET_END:
- case PTR_TO_SOCKET:
- case PTR_TO_SOCK_COMMON:
- case PTR_TO_TCP_SOCK:
- case PTR_TO_XDP_SOCK:
+ default:
verbose(env, "R%d pointer arithmetic on %s prohibited\n",
dst, reg_type_str(env, ptr_reg->type));
return -EACCES;
- default:
- break;
}
/* In case of 'scalar += pointer', dst_reg inherits pointer type and id.
--
2.34.1
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH] bpf: Refactor ptr alu checking rules to allow alu explicitly
2024-01-17 9:40 [PATCH] bpf: Refactor ptr alu checking rules to allow alu explicitly Hao Sun
@ 2024-01-17 9:42 ` Hao Sun
2024-01-18 14:38 ` Eduard Zingerman
2024-01-23 23:40 ` patchwork-bot+netdevbpf
2 siblings, 0 replies; 4+ messages in thread
From: Hao Sun @ 2024-01-17 9:42 UTC (permalink / raw)
To: bpf; +Cc: ast, andrii, daniel, eddyz87, linux-kernel
On Wed, Jan 17, 2024 at 10:40 AM Hao Sun <sunhao.th@gmail.com> wrote:
>
> Current checking rules are structured to disallow alu on particular ptr
> types explicitly, so default cases are allowed implicitly. This may lead
> to newly added ptr types being allowed unexpectedly. So restruture it to
> allow alu explicitly. The tradeoff is mainly a bit more cases added in
> the switch. The following table from Eduard summarizes the rules:
>
> | Pointer type | Arithmetics allowed |
> |---------------------+---------------------|
> | PTR_TO_CTX | yes |
> | CONST_PTR_TO_MAP | conditionally |
> | PTR_TO_MAP_VALUE | yes |
> | PTR_TO_MAP_KEY | yes |
> | PTR_TO_STACK | yes |
> | PTR_TO_PACKET_META | yes |
> | PTR_TO_PACKET | yes |
> | PTR_TO_PACKET_END | no |
> | PTR_TO_FLOW_KEYS | conditionally |
> | PTR_TO_SOCKET | no |
> | PTR_TO_SOCK_COMMON | no |
> | PTR_TO_TCP_SOCK | no |
> | PTR_TO_TP_BUFFER | yes |
> | PTR_TO_XDP_SOCK | no |
> | PTR_TO_BTF_ID | yes |
> | PTR_TO_MEM | yes |
> | PTR_TO_BUF | yes |
> | PTR_TO_FUNC | yes |
> | CONST_PTR_TO_DYNPTR | yes |
>
> The refactored rules are equivalent to the original one. Note that
> PTR_TO_FUNC and CONST_PTR_TO_DYNPTR are not reject here because: (1)
> check_mem_access() rejects load/store on those ptrs, and those ptrs
> with offset passing to calls are rejected check_func_arg_reg_off();
> (2) someone may rely on the verifier not rejecting programs earily.
>
> Signed-off-by: Hao Sun <sunhao.th@gmail.com>
> ---
Not specifying bpf-next as the target repo as my previous patch is not
in it yet.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] bpf: Refactor ptr alu checking rules to allow alu explicitly
2024-01-17 9:40 [PATCH] bpf: Refactor ptr alu checking rules to allow alu explicitly Hao Sun
2024-01-17 9:42 ` Hao Sun
@ 2024-01-18 14:38 ` Eduard Zingerman
2024-01-23 23:40 ` patchwork-bot+netdevbpf
2 siblings, 0 replies; 4+ messages in thread
From: Eduard Zingerman @ 2024-01-18 14:38 UTC (permalink / raw)
To: Hao Sun, bpf; +Cc: ast, andrii, daniel, linux-kernel
On Wed, 2024-01-17 at 10:40 +0100, Hao Sun wrote:
> Current checking rules are structured to disallow alu on particular ptr
> types explicitly, so default cases are allowed implicitly. This may lead
> to newly added ptr types being allowed unexpectedly. So restruture it to
> allow alu explicitly. The tradeoff is mainly a bit more cases added in
> the switch. The following table from Eduard summarizes the rules:
>
> | Pointer type | Arithmetics allowed |
> |---------------------+---------------------|
> | PTR_TO_CTX | yes |
> | CONST_PTR_TO_MAP | conditionally |
> | PTR_TO_MAP_VALUE | yes |
> | PTR_TO_MAP_KEY | yes |
> | PTR_TO_STACK | yes |
> | PTR_TO_PACKET_META | yes |
> | PTR_TO_PACKET | yes |
> | PTR_TO_PACKET_END | no |
> | PTR_TO_FLOW_KEYS | conditionally |
> | PTR_TO_SOCKET | no |
> | PTR_TO_SOCK_COMMON | no |
> | PTR_TO_TCP_SOCK | no |
> | PTR_TO_TP_BUFFER | yes |
> | PTR_TO_XDP_SOCK | no |
> | PTR_TO_BTF_ID | yes |
> | PTR_TO_MEM | yes |
> | PTR_TO_BUF | yes |
> | PTR_TO_FUNC | yes |
> | CONST_PTR_TO_DYNPTR | yes |
>
> The refactored rules are equivalent to the original one. Note that
> PTR_TO_FUNC and CONST_PTR_TO_DYNPTR are not reject here because: (1)
> check_mem_access() rejects load/store on those ptrs, and those ptrs
> with offset passing to calls are rejected check_func_arg_reg_off();
> (2) someone may rely on the verifier not rejecting programs earily.
>
> Signed-off-by: Hao Sun <sunhao.th@gmail.com>
> ---
Tried this on top of "Reject variable offset alu on PTR_TO_FLOW_KEYS",
all seems to be ok.
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] bpf: Refactor ptr alu checking rules to allow alu explicitly
2024-01-17 9:40 [PATCH] bpf: Refactor ptr alu checking rules to allow alu explicitly Hao Sun
2024-01-17 9:42 ` Hao Sun
2024-01-18 14:38 ` Eduard Zingerman
@ 2024-01-23 23:40 ` patchwork-bot+netdevbpf
2 siblings, 0 replies; 4+ messages in thread
From: patchwork-bot+netdevbpf @ 2024-01-23 23:40 UTC (permalink / raw)
To: Hao Sun; +Cc: bpf, ast, andrii, daniel, eddyz87, linux-kernel
Hello:
This patch was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov <ast@kernel.org>:
On Wed, 17 Jan 2024 10:40:12 +0100 you wrote:
> Current checking rules are structured to disallow alu on particular ptr
> types explicitly, so default cases are allowed implicitly. This may lead
> to newly added ptr types being allowed unexpectedly. So restruture it to
> allow alu explicitly. The tradeoff is mainly a bit more cases added in
> the switch. The following table from Eduard summarizes the rules:
>
> | Pointer type | Arithmetics allowed |
> |---------------------+---------------------|
> | PTR_TO_CTX | yes |
> | CONST_PTR_TO_MAP | conditionally |
> | PTR_TO_MAP_VALUE | yes |
> | PTR_TO_MAP_KEY | yes |
> | PTR_TO_STACK | yes |
> | PTR_TO_PACKET_META | yes |
> | PTR_TO_PACKET | yes |
> | PTR_TO_PACKET_END | no |
> | PTR_TO_FLOW_KEYS | conditionally |
> | PTR_TO_SOCKET | no |
> | PTR_TO_SOCK_COMMON | no |
> | PTR_TO_TCP_SOCK | no |
> | PTR_TO_TP_BUFFER | yes |
> | PTR_TO_XDP_SOCK | no |
> | PTR_TO_BTF_ID | yes |
> | PTR_TO_MEM | yes |
> | PTR_TO_BUF | yes |
> | PTR_TO_FUNC | yes |
> | CONST_PTR_TO_DYNPTR | yes |
>
> [...]
Here is the summary with links:
- bpf: Refactor ptr alu checking rules to allow alu explicitly
https://git.kernel.org/bpf/bpf-next/c/2ce793ebe207
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-01-23 23:40 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-17 9:40 [PATCH] bpf: Refactor ptr alu checking rules to allow alu explicitly Hao Sun
2024-01-17 9:42 ` Hao Sun
2024-01-18 14:38 ` Eduard Zingerman
2024-01-23 23:40 ` patchwork-bot+netdevbpf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).