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
| ||
|
Message-ID: <fab1c1c1-a973-a32c-8936-d0d885d4b5af@huaweicloud.com> Date: Fri, 6 Sep 2024 11:20:53 +0800 From: Hou Tao <houtao@...weicloud.com> To: Tao Chen <chen.dylane@...il.com> Cc: bpf@...r.kernel.org, linux-kernel@...r.kernel.org, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me> Subject: Re: [RFC PATCH bpf-next] bpf: Check percpu map value size first Hi, On 9/6/2024 1:14 AM, Tao Chen wrote: > Percpu map is often used, but the map value size limit often ignored, > like issue: https://github.com/iovisor/bcc/issues/2519. Actually, > percpu map value size is bound by PCPU_MIN_UNIT_SZIE, so we s/SZIE/SIZE > can check the value size whether it exceeds PCPU_MIN_UNIT_SZIE first, The same typo here. > like percpu map of local_storage. Maybe the error message seems clearer > compared with "cannot allocate memory". > > the test case we create a percpu map with large value like: > struct test_t { > int a[100000]; > }; > struct { > __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY); > __uint(max_entries, 1); > __type(key, u32); > __type(value, struct test_t); > } start SEC(".maps"); > > test on ubuntu24.04 vm: > libbpf: Error in bpf_create_map_xattr(start):Argument list too long(-7). > Retrying without BTF. Could you please convert it into a separated bpf selftest patch ? > > Signed-off-by: Tao Chen <chen.dylane@...il.com> > --- > kernel/bpf/arraymap.c | 3 +++ > kernel/bpf/hashtab.c | 3 +++ > 2 files changed, 6 insertions(+) > > diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c > index a43e62e2a8bb..7c3c32f156ff 100644 > --- a/kernel/bpf/arraymap.c > +++ b/kernel/bpf/arraymap.c > @@ -73,6 +73,9 @@ int array_map_alloc_check(union bpf_attr *attr) > /* avoid overflow on round_up(map->value_size) */ > if (attr->value_size > INT_MAX) > return -E2BIG; > + /* percpu map value size is bound by PCPU_MIN_UNIT_SIZE */ > + if (percpu && attr->value_size > PCPU_MIN_UNIT_SIZE) > + return -E2BIG; > > return 0; > } Make sense. However because the map passes round_up(attr->value_size, 8) to bpf_map_alloc_percpu(). Is it more reasonable to check round_up(value_size) > PCPU_MIN_UNIT_SIZE instead ? > diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c > index 45c7195b65ba..16d590fe1ffb 100644 > --- a/kernel/bpf/hashtab.c > +++ b/kernel/bpf/hashtab.c > @@ -462,6 +462,9 @@ static int htab_map_alloc_check(union bpf_attr *attr) > * kmalloc-able later in htab_map_update_elem() > */ > return -E2BIG; > + /* percpu map value size is bound by PCPU_MIN_UNIT_SIZE */ > + if (percpu && attr->value_size > PCPU_MIN_UNIT_SIZE) > + return -E2BIG; > The percpu allocation logic is the same as the array map: round_up(value_size, 8) is used. > return 0; > }
Powered by blists - more mailing lists