From: Andrew Morton <akpm@linux-foundation.org>
To: Anastasios Papagiannis <tasos.papagiannnis@gmail.com>
Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
viro@zeniv.linux.org.uk, brauner@kernel.org, david@kernel.org,
ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
eddyz87@gmail.com, memxor@gmail.com, kpsingh@kernel.org,
matt@bobrowski.net, song@kernel.org, utilityemal77@gmail.com,
sun.jian.kdev@gmail.com
Subject: Re: [PATCH bpf-next v4 0/7] bpf: Add user memory access kfuncs for mm_struct
Date: Fri, 4 Sep 2026 11:26:43 -0700 [thread overview]
Message-ID: <20260904112643.73448e55f788fb1cdcdd12ef@linux-foundation.org> (raw)
In-Reply-To: <20260904145340.40212-1-tasos.papagiannnis@gmail.com>
On Fri, 4 Sep 2026 17:53:33 +0300 Anastasios Papagiannis <tasos.papagiannnis@gmail.com> wrote:
> On MMU systems, during exec, argument and environment strings are copied
> into the new address space held by struct linux_binprm before that address
> space is installed on the task_struct. Existing BPF user memory helpers
> operate on the current address space or one associated with a task_struct.
> Because no task_struct refers to the new address space at this point,
> programs cannot access these strings from the bprm_check_security LSM
> hook.
>
> This series adds two sleepable BPF kfuncs for copying bytes or
> NUL-terminated strings from a trusted struct mm_struct. It also marks
> linux_binprm->mm as trusted-or-null, allowing BPF LSM programs to pass it
> to the kfuncs after a NULL check and inspect exec arguments before
> allowing the exec to continue.
Why didn't I get the usual bpfbot review emails for this series? Is
this a sign that all was clear?
> Changing bprm->mm to trusted-or-null would otherwise reject existing BPF
> programs that read through it without a NULL check. Preserve that behavior
> by allowing fault-protected reads through trusted-or-null BTF pointers.
> Pointer arithmetic, writes, atomic RMW operations, BPF_LOAD_ACQ accesses,
> and passing the pointer to a kfunc that requires a non-NULL trusted
> argument continue to require an explicit NULL check.
>
> On NOMMU systems, exec argument and environment strings remain in
> bprm->page[] until they are transferred to the new process stack. They
> cannot be accessed through bprm->mm at the bprm_check_security hook.
> The new kfuncs remain available on NOMMU for address ranges represented
> by a supplied struct mm_struct.
I'm surprised that bpf even attempts to support NOMMU. I expect the
user/tester population is zero. Perhaps just disallow this, if it
saves any effort.
next prev parent reply other threads:[~2026-09-04 18:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 14:53 [PATCH bpf-next v4 0/7] bpf: Add user memory access kfuncs for mm_struct Anastasios Papagiannis
2026-09-04 14:53 ` [PATCH bpf-next v4 1/7] mm: Add copy_remote_mm_str() Anastasios Papagiannis
2026-09-07 10:59 ` David Hildenbrand (Arm)
2026-09-07 13:41 ` Anastasios Papagiannis
2026-09-07 14:01 ` Lorenzo Stoakes (ARM)
2026-09-07 14:04 ` David Hildenbrand (Arm)
2026-09-04 14:53 ` [PATCH bpf-next v4 2/7] exec: Clear bprm->mm before dropping its reference Anastasios Papagiannis
2026-09-04 15:20 ` sashiko-bot
2026-09-04 15:30 ` Anastasios Papagiannis
2026-09-04 14:53 ` [PATCH bpf-next v4 3/7] bpf: Add user memory access kfuncs for mm_struct Anastasios Papagiannis
2026-09-04 14:53 ` [PATCH bpf-next v4 4/7] bpf: Allow reads through trusted-or-null BTF pointers Anastasios Papagiannis
2026-09-04 14:53 ` [PATCH bpf-next v4 5/7] selftests/bpf: Cover trusted-or-null BTF pointer reads Anastasios Papagiannis
2026-09-04 14:53 ` [PATCH bpf-next v4 6/7] bpf: Mark linux_binprm->mm as trusted-or-null Anastasios Papagiannis
2026-09-04 14:53 ` [PATCH bpf-next v4 7/7] selftests/bpf: Test mm_struct user memory kfuncs with linux_binprm Anastasios Papagiannis
2026-09-04 18:26 ` Andrew Morton [this message]
2026-09-07 6:58 ` [PATCH bpf-next v4 0/7] bpf: Add user memory access kfuncs for mm_struct Anastasios Papagiannis
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=20260904112643.73448e55f788fb1cdcdd12ef@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=daniel@iogearbox.net \
--cc=david@kernel.org \
--cc=eddyz87@gmail.com \
--cc=kpsingh@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matt@bobrowski.net \
--cc=memxor@gmail.com \
--cc=song@kernel.org \
--cc=sun.jian.kdev@gmail.com \
--cc=tasos.papagiannnis@gmail.com \
--cc=utilityemal77@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.