diff mbox series

Inaccurate rejection conditions

Message ID 20240320122153.3622252-1-tao.lyu@epfl.ch (mailing list archive)
State Changes Requested
Delegated to: BPF
Headers show
Series Inaccurate rejection conditions | expand

Checks

Context Check Description
netdev/series_format warning Single patches do not need cover letters; Target tree name not specified in the subject
netdev/tree_selection success Guessed tree name to be net-next
netdev/ynl success Generated files up to date; no warnings/errors; no diff in generated;
netdev/fixes_present success Fixes tag not required for -next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 951 this patch: 951
netdev/build_tools success No tools touched, skip
netdev/cc_maintainers warning 10 maintainers not CCed: haoluo@google.com john.fastabend@gmail.com eddyz87@gmail.com sdf@google.com song@kernel.org ast@kernel.org kpsingh@kernel.org martin.lau@linux.dev jolsa@kernel.org daniel@iogearbox.net
netdev/build_clang success Errors and warnings before: 957 this patch: 957
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 968 this patch: 968
netdev/checkpatch warning WARNING: Missing commit description - Add an appropriate one
netdev/build_clang_rust success No Rust files in patch. Skipping build
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0
bpf/vmtest-bpf-next-PR success PR summary
bpf/vmtest-bpf-next-VM_Test-14 success Logs for s390x-gcc / test (test_progs, false, 360) / test_progs on s390x with gcc
bpf/vmtest-bpf-next-VM_Test-16 success Logs for s390x-gcc / test (test_verifier, false, 360) / test_verifier on s390x with gcc
bpf/vmtest-bpf-next-VM_Test-0 success Logs for Lint
bpf/vmtest-bpf-next-VM_Test-3 success Logs for Validate matrix.py
bpf/vmtest-bpf-next-VM_Test-2 success Logs for Unittests
bpf/vmtest-bpf-next-VM_Test-1 success Logs for ShellCheck
bpf/vmtest-bpf-next-VM_Test-5 success Logs for aarch64-gcc / build-release
bpf/vmtest-bpf-next-VM_Test-4 success Logs for aarch64-gcc / build / build for aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-15 success Logs for x86_64-gcc / build-release
bpf/vmtest-bpf-next-VM_Test-12 success Logs for s390x-gcc / build-release
bpf/vmtest-bpf-next-VM_Test-13 success Logs for set-matrix
bpf/vmtest-bpf-next-VM_Test-10 success Logs for aarch64-gcc / veristat
bpf/vmtest-bpf-next-VM_Test-11 success Logs for s390x-gcc / build / build for s390x with gcc
bpf/vmtest-bpf-next-VM_Test-35 success Logs for x86_64-llvm-18 / build / build for x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-6 success Logs for aarch64-gcc / test (test_maps, false, 360) / test_maps on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-17 success Logs for s390x-gcc / veristat
bpf/vmtest-bpf-next-VM_Test-19 success Logs for x86_64-gcc / build / build for x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-34 success Logs for x86_64-llvm-17 / veristat
bpf/vmtest-bpf-next-VM_Test-42 success Logs for x86_64-llvm-18 / veristat
bpf/vmtest-bpf-next-VM_Test-18 success Logs for set-matrix
bpf/vmtest-bpf-next-VM_Test-28 success Logs for x86_64-llvm-17 / build / build for x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-36 success Logs for x86_64-llvm-18 / build-release / build for x86_64 with llvm-18 and -O2 optimization
bpf/vmtest-bpf-next-VM_Test-9 success Logs for aarch64-gcc / test (test_verifier, false, 360) / test_verifier on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-7 success Logs for aarch64-gcc / test (test_progs, false, 360) / test_progs on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-29 success Logs for x86_64-llvm-17 / build-release / build for x86_64 with llvm-17 and -O2 optimization
bpf/vmtest-bpf-next-VM_Test-20 success Logs for x86_64-gcc / build-release
bpf/vmtest-bpf-next-VM_Test-25 success Logs for x86_64-gcc / test (test_progs_parallel, true, 30) / test_progs_parallel on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-30 success Logs for x86_64-llvm-17 / test (test_maps, false, 360) / test_maps on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-26 success Logs for x86_64-gcc / test (test_verifier, false, 360) / test_verifier on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-8 success Logs for aarch64-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-27 success Logs for x86_64-gcc / veristat / veristat on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-33 success Logs for x86_64-llvm-17 / test (test_verifier, false, 360) / test_verifier on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-24 success Logs for x86_64-gcc / test (test_progs_no_alu32_parallel, true, 30) / test_progs_no_alu32_parallel on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-31 success Logs for x86_64-llvm-17 / test (test_progs, false, 360) / test_progs on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-21 success Logs for x86_64-gcc / test (test_maps, false, 360) / test_maps on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-41 success Logs for x86_64-llvm-18 / test (test_verifier, false, 360) / test_verifier on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-37 success Logs for x86_64-llvm-18 / test (test_maps, false, 360) / test_maps on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-22 success Logs for x86_64-gcc / test (test_progs, false, 360) / test_progs on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-32 success Logs for x86_64-llvm-17 / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-39 success Logs for x86_64-llvm-18 / test (test_progs_cpuv4, false, 360) / test_progs_cpuv4 on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-23 success Logs for x86_64-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-38 success Logs for x86_64-llvm-18 / test (test_progs, false, 360) / test_progs on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-40 success Logs for x86_64-llvm-18 / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with llvm-18

Commit Message

Tao Lyu March 20, 2024, 12:21 p.m. UTC
Signed-off-by: Tao Lyu <tao.lyu@epfl.ch>
---
 kernel/bpf/verifier.c | 1 +
 1 file changed, 1 insertion(+)

Hi,

I am sorry to bother you due to my confusion on constraints about stack writes.

1. When an instruction stores 64-bit values onto the stack with fixed offset and BPF_CAP only,
   the verifier marks the stack slot type as STACK_SPILL, no matter whether they are scalar or pointers.

2. Then, a store instruction with a **32-bit scalar value** on the same stack slot leads to a verification rejection.
   As it says, this might corrupt the stack pointer by asserting if the stack slot type is STACK_SPILL. 
   However, even if the stack slot type is STACK_SPILL, it might store a 64-bit scalar and not a stack pointer.
   IMHO, this "issue" might originate from the incomplete conditions in the check_stack_write_fixed_off() function below.
   It only checks if the stack slot is a spilled register but forgets to check if the spilled register type is a pointer.

 4479 static int check_stack_write_fixed_off(struct bpf_verifier_env *env,
 ...
 4494     if (!env->allow_ptr_leaks &&
 4495         is_spilled_reg(&state->stack[spi]) &&
 4496         size != BPF_REG_SIZE) {
 4497         verbose(env, "attempt to corrupt spilled pointer on stack\n");
 4498         return -EACCES;
 4499     }
 ...
 4600 }

Below is an example bpf program, which stores a 64-bit and 32-bit immediate value on the same stack slot.
But the second one gets rejected due to the above.

0: R1=ctx() R10=fp0
; asm volatile ( @ repro.bpf.c:679
0: (7a) *(u64 *)(r10 -8) = 1          ; R10=fp0 fp-8_w=1
1: (62) *(u32 *)(r10 -8) = 1
attempt to corrupt spilled pointer on stack
processed 2 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0.

If my understanding is correct, then we can apply the attached patch.

Comments

Andrii Nakryiko April 2, 2024, 5:50 p.m. UTC | #1
On Wed, Mar 20, 2024 at 5:28 AM Tao Lyu <tao.lyu@epfl.ch> wrote:
>
> Signed-off-by: Tao Lyu <tao.lyu@epfl.ch>
> ---
>  kernel/bpf/verifier.c | 1 +
>  1 file changed, 1 insertion(+)
>
> Hi,
>
> I am sorry to bother you due to my confusion on constraints about stack writes.
>
> 1. When an instruction stores 64-bit values onto the stack with fixed offset and BPF_CAP only,
>    the verifier marks the stack slot type as STACK_SPILL, no matter whether they are scalar or pointers.
>
> 2. Then, a store instruction with a **32-bit scalar value** on the same stack slot leads to a verification rejection.
>    As it says, this might corrupt the stack pointer by asserting if the stack slot type is STACK_SPILL.
>    However, even if the stack slot type is STACK_SPILL, it might store a 64-bit scalar and not a stack pointer.
>    IMHO, this "issue" might originate from the incomplete conditions in the check_stack_write_fixed_off() function below.
>    It only checks if the stack slot is a spilled register but forgets to check if the spilled register type is a pointer.
>
>  4479 static int check_stack_write_fixed_off(struct bpf_verifier_env *env,
>  ...
>  4494     if (!env->allow_ptr_leaks &&
>  4495         is_spilled_reg(&state->stack[spi]) &&
>  4496         size != BPF_REG_SIZE) {
>  4497         verbose(env, "attempt to corrupt spilled pointer on stack\n");
>  4498         return -EACCES;
>  4499     }
>  ...
>  4600 }
>
> Below is an example bpf program, which stores a 64-bit and 32-bit immediate value on the same stack slot.
> But the second one gets rejected due to the above.
>
> 0: R1=ctx() R10=fp0
> ; asm volatile ( @ repro.bpf.c:679
> 0: (7a) *(u64 *)(r10 -8) = 1          ; R10=fp0 fp-8_w=1
> 1: (62) *(u32 *)(r10 -8) = 1
> attempt to corrupt spilled pointer on stack
> processed 2 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0.
>
> If my understanding is correct, then we can apply the attached patch.
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index de7813947981..65f7eb315e9c 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -4493,6 +4493,7 @@ static int check_stack_write_fixed_off(struct bpf_verifier_env *env,
>          */
>         if (!env->allow_ptr_leaks &&
>             is_spilled_reg(&state->stack[spi]) &&
> +           state->stack[spi].spilled_ptr.type != SCALAR_VALUE &&

I think it's possible to easily convert PTR_TO_MEM kind of register to
SCALAR_VALUE through arithmetic operations, and so allowing to spill
SCALAR_VALUE to stack is basically just as dangerous as spilling
PTR_TO_MEM directly.

So it feels a bit dangerous to do this.

pw-bot: cr

>             size != BPF_REG_SIZE) {
>                 verbose(env, "attempt to corrupt spilled pointer on stack\n");
>                 return -EACCES;
> --
> 2.25.1
>
Tao Lyu April 2, 2024, 7:05 p.m. UTC | #2
>>
>> Signed-off-by: Tao Lyu <tao.lyu@epfl.ch>
>> ---
>>  kernel/bpf/verifier.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> Hi,
>>
>> I am sorry to bother you due to my confusion on constraints about stack writes.
>>
>> 1. When an instruction stores 64-bit values onto the stack with fixed offset and BPF_CAP only,
>>    the verifier marks the stack slot type as STACK_SPILL, no matter whether they are scalar or pointers.
>>
>> 2. Then, a store instruction with a **32-bit scalar value** on the same stack slot leads to a verification rejection.
>>    As it says, this might corrupt the stack pointer by asserting if the stack slot type is STACK_SPILL.
>>    However, even if the stack slot type is STACK_SPILL, it might store a 64-bit scalar and not a stack pointer.
>>    IMHO, this "issue" might originate from the incomplete conditions in the check_stack_write_fixed_off() function below.
>>    It only checks if the stack slot is a spilled register but forgets to check if the spilled register type is a pointer.
>>
>>  4479 static int check_stack_write_fixed_off(struct bpf_verifier_env *env,
>>  ...
>>  4494     if (!env->allow_ptr_leaks &&
>>  4495         is_spilled_reg(&state->stack[spi]) &&
>>  4496         size != BPF_REG_SIZE) {
>>  4497         verbose(env, "attempt to corrupt spilled pointer on stack\n");
>>  4498         return -EACCES;
>>  4499     }
>>  ...
>>  4600 }
>>
>> Below is an example bpf program, which stores a 64-bit and 32-bit immediate value on the same stack slot.
>> But the second one gets rejected due to the above.
>>
>> 0: R1=ctx() R10=fp0
>> ; asm volatile ( @ repro.bpf.c:679
>> 0: (7a) *(u64 *)(r10 -8) = 1          ; R10=fp0 fp-8_w=1
>> 1: (62) *(u32 *)(r10 -8) = 1
>> attempt to corrupt spilled pointer on stack
>> processed 2 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0.
>>
>> If my understanding is correct, then we can apply the attached patch.
>>
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index de7813947981..65f7eb315e9c 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -4493,6 +4493,7 @@ static int check_stack_write_fixed_off(struct bpf_verifier_env *env,
>>          */
>>         if (!env->allow_ptr_leaks &&
>>             is_spilled_reg(&state->stack[spi]) &&
>> +           state->stack[spi].spilled_ptr.type != SCALAR_VALUE &&
>
> I think it's possible to easily convert PTR_TO_MEM kind of register to
> SCALAR_VALUE through arithmetic operations, and so allowing to spill
> SCALAR_VALUE to stack is basically just as dangerous as spilling
> PTR_TO_MEM directly.
>
> So it feels a bit dangerous to do this.

Hi Andrii, thanks for the reply.

I think you might misunderstand this issue.
Let me rephrase it below:

** The verifier should allow partially overwriting an 8-byte stack slot
that contains a spilled scalar instead of rejecting it,
as the example shows below.** 

0: R1=ctx() R10=fp0
; asm volatile ( @ repro.bpf.c:679
0: (7a) *(u64 *)(r10 -8) = 1          ; R10=fp0 fp-8_w=1
1: (62) *(u32 *)(r10 -8) = 1
attempt to corrupt spilled pointer on stack

In this case, it's about overwriting a spill of a 64-bit scalar 
with another scalar with a smaller size (e.g., 32-bit). 
Pointers are not related to this IIUC.

Thanks for your time again.

>
>>             size != BPF_REG_SIZE) {
>>                 verbose(env, "attempt to corrupt spilled pointer on stack\n");
>>                 return -EACCES;
>> --
>> 2.25.1
>>
Andrii Nakryiko April 3, 2024, 4:30 p.m. UTC | #3
On Tue, Apr 2, 2024 at 12:05 PM Tao Lyu <tao.lyu@epfl.ch> wrote:
>
> >>
> >> Signed-off-by: Tao Lyu <tao.lyu@epfl.ch>
> >> ---
> >>  kernel/bpf/verifier.c | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> Hi,
> >>
> >> I am sorry to bother you due to my confusion on constraints about stack writes.
> >>
> >> 1. When an instruction stores 64-bit values onto the stack with fixed offset and BPF_CAP only,
> >>    the verifier marks the stack slot type as STACK_SPILL, no matter whether they are scalar or pointers.
> >>
> >> 2. Then, a store instruction with a **32-bit scalar value** on the same stack slot leads to a verification rejection.
> >>    As it says, this might corrupt the stack pointer by asserting if the stack slot type is STACK_SPILL.
> >>    However, even if the stack slot type is STACK_SPILL, it might store a 64-bit scalar and not a stack pointer.
> >>    IMHO, this "issue" might originate from the incomplete conditions in the check_stack_write_fixed_off() function below.
> >>    It only checks if the stack slot is a spilled register but forgets to check if the spilled register type is a pointer.
> >>
> >>  4479 static int check_stack_write_fixed_off(struct bpf_verifier_env *env,
> >>  ...
> >>  4494     if (!env->allow_ptr_leaks &&
> >>  4495         is_spilled_reg(&state->stack[spi]) &&
> >>  4496         size != BPF_REG_SIZE) {
> >>  4497         verbose(env, "attempt to corrupt spilled pointer on stack\n");
> >>  4498         return -EACCES;
> >>  4499     }
> >>  ...
> >>  4600 }
> >>
> >> Below is an example bpf program, which stores a 64-bit and 32-bit immediate value on the same stack slot.
> >> But the second one gets rejected due to the above.
> >>
> >> 0: R1=ctx() R10=fp0
> >> ; asm volatile ( @ repro.bpf.c:679
> >> 0: (7a) *(u64 *)(r10 -8) = 1          ; R10=fp0 fp-8_w=1
> >> 1: (62) *(u32 *)(r10 -8) = 1
> >> attempt to corrupt spilled pointer on stack
> >> processed 2 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0.
> >>
> >> If my understanding is correct, then we can apply the attached patch.
> >>
> >> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> >> index de7813947981..65f7eb315e9c 100644
> >> --- a/kernel/bpf/verifier.c
> >> +++ b/kernel/bpf/verifier.c
> >> @@ -4493,6 +4493,7 @@ static int check_stack_write_fixed_off(struct bpf_verifier_env *env,
> >>          */
> >>         if (!env->allow_ptr_leaks &&
> >>             is_spilled_reg(&state->stack[spi]) &&
> >> +           state->stack[spi].spilled_ptr.type != SCALAR_VALUE &&
> >
> > I think it's possible to easily convert PTR_TO_MEM kind of register to
> > SCALAR_VALUE through arithmetic operations, and so allowing to spill
> > SCALAR_VALUE to stack is basically just as dangerous as spilling
> > PTR_TO_MEM directly.
> >
> > So it feels a bit dangerous to do this.
>
> Hi Andrii, thanks for the reply.
>
> I think you might misunderstand this issue.
> Let me rephrase it below:
>
> ** The verifier should allow partially overwriting an 8-byte stack slot
> that contains a spilled scalar instead of rejecting it,
> as the example shows below.**
>
> 0: R1=ctx() R10=fp0
> ; asm volatile ( @ repro.bpf.c:679
> 0: (7a) *(u64 *)(r10 -8) = 1          ; R10=fp0 fp-8_w=1
> 1: (62) *(u32 *)(r10 -8) = 1
> attempt to corrupt spilled pointer on stack
>
> In this case, it's about overwriting a spill of a 64-bit scalar
> with another scalar with a smaller size (e.g., 32-bit).
> Pointers are not related to this IIUC.
>

Ah, you are right, I misunderstood the use case. From my perspective
what you propose makes sense. Please prepare an official patch with a
proper commit message and send it again to bpf@vger.kernel.org.

> Thanks for your time again.
>
> >
> >>             size != BPF_REG_SIZE) {
> >>                 verbose(env, "attempt to corrupt spilled pointer on stack\n");
> >>                 return -EACCES;
> >> --
> >> 2.25.1
> >>
diff mbox series

Patch

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index de7813947981..65f7eb315e9c 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -4493,6 +4493,7 @@  static int check_stack_write_fixed_off(struct bpf_verifier_env *env,
 	 */
 	if (!env->allow_ptr_leaks &&
 	    is_spilled_reg(&state->stack[spi]) &&
+	    state->stack[spi].spilled_ptr.type != SCALAR_VALUE &&
 	    size != BPF_REG_SIZE) {
 		verbose(env, "attempt to corrupt spilled pointer on stack\n");
 		return -EACCES;