From: Andrii Nakryiko <andrii@kernel.org>
To: <bpf@vger.kernel.org>, <ast@kernel.org>, <daniel@iogearbox.net>
Cc: <andrii@kernel.org>, <kernel-team@fb.com>
Subject: [PATCH v2 bpf-next 3/4] bpf: remove obsolete KMALLOC_MAX_SIZE restriction on array map value size
Date: Thu, 14 Jul 2022 22:31:45 -0700 [thread overview]
Message-ID: <20220715053146.1291891-4-andrii@kernel.org> (raw)
In-Reply-To: <20220715053146.1291891-1-andrii@kernel.org>
Syscall-side map_lookup_elem() and map_update_elem() used to use
kmalloc() to allocate temporary buffers of value_size, so
KMALLOC_MAX_SIZE limit on value_size made sense to prevent creation of
array map that won't be accessible through syscall interface.
But this limitation since has been lifted by relying on kvmalloc() in
syscall handling code. So remove KMALLOC_MAX_SIZE, which among other
things means that it's possible to have BPF global variable sections
(.bss, .data, .rodata) bigger than 8MB now. Keep the sanity check to
prevent trivial overflows like round_up(map->value_size, 8) and restrict
value size to <= INT_MAX (2GB).
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
---
kernel/bpf/arraymap.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 98ee09155151..d3e734bf8056 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -70,10 +70,8 @@ int array_map_alloc_check(union bpf_attr *attr)
attr->map_flags & BPF_F_PRESERVE_ELEMS)
return -EINVAL;
- if (attr->value_size > KMALLOC_MAX_SIZE)
- /* if value_size is bigger, the user space won't be able to
- * access the elements.
- */
+ /* avoid overflow on round_up(map->value_size) */
+ if (attr->value_size > INT_MAX)
return -E2BIG;
return 0;
--
2.30.2
next prev parent reply other threads:[~2022-07-15 5:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-15 5:31 [PATCH v2 bpf-next 0/4] BPF array map fixes and improvements Andrii Nakryiko
2022-07-15 5:31 ` [PATCH v2 bpf-next 1/4] bpf: fix potential 32-bit overflow when accessing ARRAY map element Andrii Nakryiko
2022-07-15 5:31 ` [PATCH v2 bpf-next 2/4] bpf: make uniform use of array->elem_size everywhere in arraymap.c Andrii Nakryiko
2022-07-15 5:31 ` Andrii Nakryiko [this message]
2022-07-15 5:31 ` [PATCH v2 bpf-next 4/4] selftests/bpf: validate .bss section bigger than 8MB is possible now Andrii Nakryiko
2022-07-15 16:29 ` [PATCH v2 bpf-next 0/4] BPF array map fixes and improvements Yonghong Song
2022-07-19 16:50 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220715053146.1291891-4-andrii@kernel.org \
--to=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox