lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 22 Jul 2022 09:16:34 -0700 From: Alexei Starovoitov <alexei.starovoitov@...il.com> To: Benjamin Tissoires <benjamin.tissoires@...hat.com> Cc: Greg KH <gregkh@...uxfoundation.org>, Jiri Kosina <jikos@...nel.org>, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau <kafai@...com>, Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>, Kumar Kartikeya Dwivedi <memxor@...il.com>, John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>, Shuah Khan <shuah@...nel.org>, Dave Marchevsky <davemarchevsky@...com>, Joe Stringer <joe@...ium.io>, Jonathan Corbet <corbet@....net>, Tero Kristo <tero.kristo@...ux.intel.com>, LKML <linux-kernel@...r.kernel.org>, "open list:HID CORE LAYER" <linux-input@...r.kernel.org>, Network Development <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>, "open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@...r.kernel.org>, "open list:DOCUMENTATION" <linux-doc@...r.kernel.org> Subject: Re: [PATCH bpf-next v8 02/24] bpf/verifier: allow kfunc to read user provided context On Fri, Jul 22, 2022 at 1:46 AM Benjamin Tissoires <benjamin.tissoires@...hat.com> wrote: > > When a kfunc was trying to access data from context in a syscall eBPF > program, the verifier was rejecting the call. > This is because the syscall context is not known at compile time, and > so we need to check this when actually accessing it. > > Check for the valid memory access and allow such situation to happen. > > Acked-by: Kumar Kartikeya Dwivedi <memxor@...il.com> > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@...hat.com> > > --- > > changes in v8: > - fixup comment > - return -EACCESS instead of -EINVAL for consistency > > changes in v7: > - renamed access_t into atype > - allow zero-byte read > - check_mem_access() to the correct offset/size > > new in v6 > --- > kernel/bpf/verifier.c | 21 +++++++++++++++++++++ > 1 file changed, 21 insertions(+) > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > index 7c1e056624f9..c807c5d7085a 100644 > --- a/kernel/bpf/verifier.c > +++ b/kernel/bpf/verifier.c > @@ -248,6 +248,7 @@ struct bpf_call_arg_meta { > struct bpf_map *map_ptr; > bool raw_mode; > bool pkt_access; > + bool is_kfunc; > u8 release_regno; > int regno; > int access_size; > @@ -5170,6 +5171,7 @@ static int check_helper_mem_access(struct bpf_verifier_env *env, int regno, > struct bpf_call_arg_meta *meta) > { > struct bpf_reg_state *regs = cur_regs(env), *reg = ®s[regno]; > + enum bpf_prog_type prog_type = resolve_prog_type(env->prog); > u32 *max_access; > > switch (base_type(reg->type)) { > @@ -5223,6 +5225,24 @@ static int check_helper_mem_access(struct bpf_verifier_env *env, int regno, > env, > regno, reg->off, access_size, > zero_size_allowed, ACCESS_HELPER, meta); > + case PTR_TO_CTX: > + /* in case of a kfunc called in a program of type SYSCALL, the context is > + * user supplied, so not computed statically. > + * Dynamically check it now > + */ > + if (prog_type == BPF_PROG_TYPE_SYSCALL && meta && meta->is_kfunc) { prog_type check looks a bit odd here. Can we generalize with if (!env->ops->convert_ctx_access In other words any program type that doesn't have ctx rewrites can use helpers to access ctx fields ? Also why kfunc only? It looks safe to allow normal helpers as well.
Powered by blists - more mailing lists