| Message ID | 20240411122752.2873562-7-xukuohai@huaweicloud.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Add check for bpf lsm return value | expand |
On Thu, Apr 11, 2024 at 08:27:47PM +0800, Xu Kuohai wrote: > [...] > 24: (b4) w0 = -1 ; R0_w=0xffffffff > ; int BPF_PROG(test_int_hook, struct vm_area_struct *vma, @ lsm.c:89 > 25: (95) exit > At program exit the register R0 has smin=4294967295 smax=4294967295 should have been in [-4095, 0] > > It can be seen that instruction "w0 = -1" zero extended -1 to 64-bit > register r0, setting both smin and smax values of r0 to 4294967295. > This resulted in a false reject when r0 was checked with range [-4095, 0]. > > Given bpf_retval_range is a 32-bit range, this patch fixes it by > changing the compare between r0 and return range from 64-bit > operation to 32-bit operation. > > Fixes: 8fa4ecd49b81 ("bpf: enforce exact retval range on subprog/callback exit") > Signed-off-by: Xu Kuohai <xukuohai@huawei.com> > --- > kernel/bpf/verifier.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > index 05c7c5f2bec0..5393d576c76f 100644 > --- a/kernel/bpf/verifier.c > +++ b/kernel/bpf/verifier.c > @@ -9879,7 +9879,7 @@ static bool in_rbtree_lock_required_cb(struct bpf_verifier_env *env) > > static bool retval_range_within(struct bpf_retval_range range, const struct bpf_reg_state *reg) > { > - return range.minval <= reg->smin_value && reg->smax_value <= range.maxval; > + return range.minval <= reg->s32_min_value && reg->s32_max_value <= range.maxval; Logic-wise LGTM While the status-quo is that the return value is always truncated to 32-bit, looking back there was an attempt to use 64-bit return value for bpf_prog_run[1] (not merged due to issue on 32-bit architectures). Also from the reading of BPF standardization ABI it would be inferred that return value is in 64-bit range: BPF has 10 general purpose registers and a read-only frame pointer register, all of which are 64-bits wide. The BPF calling convention is defined as: * R0: return value from function calls, and exit value for BPF programs ... So add relevant people into the thread for opinions. 1: https://lore.kernel.org/bpf/20221115193911.u6prvskdzr5jevni@apollo/
On Thu, Apr 11, 2024 at 5:24 AM Xu Kuohai <xukuohai@huaweicloud.com> wrote: > > From: Xu Kuohai <xukuohai@huawei.com> > > After checking lsm hook return range in verifier, the test case > "test_progs -t test_lsm" failed, and the failure log says: > > libbpf: prog 'test_int_hook': BPF program load failed: Invalid argument > libbpf: prog 'test_int_hook': -- BEGIN PROG LOAD LOG -- > 0: R1=ctx() R10=fp0 > ; int BPF_PROG(test_int_hook, struct vm_area_struct *vma, @ lsm.c:89 > 0: (79) r0 = *(u64 *)(r1 +24) ; R0_w=scalar(smin=smin32=-4095,smax=smax32=0) R1=ctx() > > [...] > > 24: (b4) w0 = -1 ; R0_w=0xffffffff > ; int BPF_PROG(test_int_hook, struct vm_area_struct *vma, @ lsm.c:89 > 25: (95) exit > At program exit the register R0 has smin=4294967295 smax=4294967295 should have been in [-4095, 0] > > It can be seen that instruction "w0 = -1" zero extended -1 to 64-bit > register r0, setting both smin and smax values of r0 to 4294967295. > This resulted in a false reject when r0 was checked with range [-4095, 0]. > > Given bpf_retval_range is a 32-bit range, this patch fixes it by > changing the compare between r0 and return range from 64-bit > operation to 32-bit operation. > > Fixes: 8fa4ecd49b81 ("bpf: enforce exact retval range on subprog/callback exit") > Signed-off-by: Xu Kuohai <xukuohai@huawei.com> > --- > kernel/bpf/verifier.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > index 05c7c5f2bec0..5393d576c76f 100644 > --- a/kernel/bpf/verifier.c > +++ b/kernel/bpf/verifier.c > @@ -9879,7 +9879,7 @@ static bool in_rbtree_lock_required_cb(struct bpf_verifier_env *env) > > static bool retval_range_within(struct bpf_retval_range range, const struct bpf_reg_state *reg) > { > - return range.minval <= reg->smin_value && reg->smax_value <= range.maxval; > + return range.minval <= reg->s32_min_value && reg->s32_max_value <= range.maxval; are all BPF programs treated as if they return int instead of long? If not, we probably should have a bool flag in bpf_retval_range whether comparison should be 32-bit or 64-bit? > } > > static int prepare_func_exit(struct bpf_verifier_env *env, int *insn_idx) > -- > 2.30.2 >
On 4/26/2024 7:41 AM, Andrii Nakryiko wrote: > On Thu, Apr 11, 2024 at 5:24 AM Xu Kuohai <xukuohai@huaweicloud.com> wrote: >> >> From: Xu Kuohai <xukuohai@huawei.com> >> >> After checking lsm hook return range in verifier, the test case >> "test_progs -t test_lsm" failed, and the failure log says: >> >> libbpf: prog 'test_int_hook': BPF program load failed: Invalid argument >> libbpf: prog 'test_int_hook': -- BEGIN PROG LOAD LOG -- >> 0: R1=ctx() R10=fp0 >> ; int BPF_PROG(test_int_hook, struct vm_area_struct *vma, @ lsm.c:89 >> 0: (79) r0 = *(u64 *)(r1 +24) ; R0_w=scalar(smin=smin32=-4095,smax=smax32=0) R1=ctx() >> >> [...] >> >> 24: (b4) w0 = -1 ; R0_w=0xffffffff >> ; int BPF_PROG(test_int_hook, struct vm_area_struct *vma, @ lsm.c:89 >> 25: (95) exit >> At program exit the register R0 has smin=4294967295 smax=4294967295 should have been in [-4095, 0] >> >> It can be seen that instruction "w0 = -1" zero extended -1 to 64-bit >> register r0, setting both smin and smax values of r0 to 4294967295. >> This resulted in a false reject when r0 was checked with range [-4095, 0]. >> >> Given bpf_retval_range is a 32-bit range, this patch fixes it by >> changing the compare between r0 and return range from 64-bit >> operation to 32-bit operation. >> >> Fixes: 8fa4ecd49b81 ("bpf: enforce exact retval range on subprog/callback exit") >> Signed-off-by: Xu Kuohai <xukuohai@huawei.com> >> --- >> kernel/bpf/verifier.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c >> index 05c7c5f2bec0..5393d576c76f 100644 >> --- a/kernel/bpf/verifier.c >> +++ b/kernel/bpf/verifier.c >> @@ -9879,7 +9879,7 @@ static bool in_rbtree_lock_required_cb(struct bpf_verifier_env *env) >> >> static bool retval_range_within(struct bpf_retval_range range, const struct bpf_reg_state *reg) >> { >> - return range.minval <= reg->smin_value && reg->smax_value <= range.maxval; >> + return range.minval <= reg->s32_min_value && reg->s32_max_value <= range.maxval; > > are all BPF programs treated as if they return int instead of long? If > not, we probably should have a bool flag in bpf_retval_range whether > comparison should be 32-bit or 64-bit? > It seems that when a fmod_return prog is attached to a kernel function that returns long value, the bpf prog should also return long value. To confirm it, I'll try to find an example or construct a case for this. >> } >> >> static int prepare_func_exit(struct bpf_verifier_env *env, int *insn_idx) >> -- >> 2.30.2 >> >
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 05c7c5f2bec0..5393d576c76f 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -9879,7 +9879,7 @@ static bool in_rbtree_lock_required_cb(struct bpf_verifier_env *env) static bool retval_range_within(struct bpf_retval_range range, const struct bpf_reg_state *reg) { - return range.minval <= reg->smin_value && reg->smax_value <= range.maxval; + return range.minval <= reg->s32_min_value && reg->s32_max_value <= range.maxval; } static int prepare_func_exit(struct bpf_verifier_env *env, int *insn_idx)