[LTP] [PATCH v2 4/4] bpf_prog05: Drop CAP_BPF and check if ptr arithmetic is allowed

[Richard Palethorpe]

Hello Joerg,

Joerg Vehlow <lkml@jv-coder.de> writes:

> Hi Richard,
>
> Am 8/31/2021 um 11:10 AM schrieb Richard Palethorpe via ltp:
>> On older kernels pointer arithmetic requires CAP_BPF. They also lack
>> the ability to call BPF subprogs. This makes it difficult to exploit
>> the div/mod behavior.
>> Older kernels leave div/mod by zero undefined. This causes the test
>> to
>> fail and backporting the new behavior is difficult. So when we find
>> that pointer arithmetic is not possible without CAP_BPF we can return
>> TCONF. Because in this case, we know the test will fail, the risk is
>> limited and there is little that can be done about it.
>
> What does older kernel mean here?

I'm refering to multiple different kernel versions (perhaps
confusingly). On much older kernels we don't have any issues because
pointer arithmetic was not possible in sensitive contexts.

Then it was made possible, but div/mod by zero was undefined. Then that
was fixed, but IIRC there were other issues. Depending on what commits
you have, any number of outcomes are possible.

>
>> +
>> +	if (ret != -1)
>> +		tst_brk(TBROK, "Invalid bpf() return value: %d", ret);
>> +
>> +	if (log[0] != 0)
>> +		tst_brk(TCONF | TERRNO, "No pointer arithmetic:\n %s", log);
> This check now fails for me with the following output, where the test
> was successful, before this patch. The kernel is a non-standard suse 
> 5.3.18 with realtime patches.
>
> bpf_prog05.c:100: TCONF: No pointer arithmetic:
>  0: (bf) r2 = r10
> 1: (b7) r3 = -1
> 2: (0f) r2 += r3
> 3: (72) *(u8 *)(r2 +0) = 0
> 4: (b7) r0 = 0
> 5: (95) exit
>
> from 2 to 3 (speculative execution): R1=ctx(id=0,off=0,imm=0) R2_w=fp0
> R3_w=invP-1 R10=fp0
> 3: (72) *(u8 *)(r2 +0) = 0
> invalid stack off=0 size=1
> processed 7 insns (limit 1000000) max_states_per_insn 0 total_states 0
> peak_states 0 mark_read 0
> : EACCES (13)
>
>
> Is this too old? But then again, the test was successful before this
> patch and your commit message states, that it was not successful on 
> "older kernels".

Are you testing on ARM? eBPF adopted the ARM behavior when dividing by
zero.

-- 
Thank you,
Richard.