From: Matt Bobrowski <mattbobrowski@google.com>
To: bpf@vger.kernel.org
Cc: ast@kernel.org, andrii@kernel.org, kpsingh@google.com,
jannh@google.com, jolsa@kernel.org, daniel@iogearbox.net,
brauner@kernel.org, torvalds@linux-foundation.org,
linux-fsdevel@vger.kernel.org
Subject: [PATCH v2 bpf-next 4/9] bpf: add new acquire/release based BPF kfuncs for exe_file
Date: Wed, 6 Mar 2024 07:40:00 +0000 [thread overview]
Message-ID: <6a5d425e52eb4d8f7539e841494eac36688ab0da.1709675979.git.mattbobrowski@google.com> (raw)
In-Reply-To: <cover.1709675979.git.mattbobrowski@google.com>
It is rather common for BPF LSM program types to perform the struct
walk current->mm->exe_file and subsequently operate on fields of the
backing file. At times, some of these operations involve passing a
exe_file's field on to BPF helpers and such
i.e. bpf_d_path(¤t->mm->exe_file->f_path). However, doing so
isn't necessarily always reliable as the backing file that exe_file is
pointing to may be in the midst of being torn down and handing
anything contained within this file to BPF helpers and such can lead
to memory corruption issues [0].
To alleviate possibly operating on semi-torn down instances of
current->mm->exe_file we introduce a set of BPF kfuncs that posses
KF_ACQUIRE/KF_RELEASE based semantics. Such BPF kfuncs will allow BPF
LSM program types to reliably get/put a reference on a
current->mm->exe_file.
The following new BPF kfuncs have been added:
struct file *bpf_get_task_exe_file(struct task_struct *task);
struct file *bpf_get_mm_exe_file(struct mm_struct *mm);
void bpf_put_file(struct file *f);
Internally, these new BPF kfuncs simply call the preexisting in-kernel
functions get_task_exe_file(), get_mm_exe_file(), and fput()
accordingly. From a technical standpoint, there's absolutely no need
to re-implement such helpers just for BPF as they're currently scoped
to BPF LSM program types.
Note that we explicitly do not explicitly rely on the use of very low
level in-kernel functions like get_file_rcu() and get_file_active() to
acquire a reference on current->mm->exe_file and such. This is super
subtle code and we probably want to avoid exposing any such subtleties
to BPF in the form of BPF kfuncs. Additionally, the usage of a double
pointer i.e. struct file **, isn't something that the BPF verifier
currently recognizes nor has any intention to recognize for the
foreseeable future.
[0] https://lore.kernel.org/bpf/CAG48ez0ppjcT=QxU-jtCUfb5xQb3mLr=5FcwddF_VKfEBPs_Dg@mail.gmail.com/
Signed-off-by: Matt Bobrowski <mattbobrowski@google.com>
---
kernel/trace/bpf_trace.c | 56 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 801808b6efb0..539c58db74d7 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -1518,12 +1518,68 @@ __bpf_kfunc void bpf_mm_drop(struct mm_struct *mm)
mmdrop(mm);
}
+/**
+ * bpf_get_task_exe_file - get a reference on the exe_file associated with the
+ * mm_struct that is nested within the supplied
+ * task_struct
+ * @task: task_struct of which the nested mm_struct's exe_file is to be
+ * referenced
+ *
+ * Get a reference on the exe_file that is associated with the mm_struct nested
+ * within the supplied *task*. A reference on a file pointer acquired by this
+ * kfunc must be released using bpf_put_file(). Internally, this kfunc leans on
+ * get_task_exe_file(), such that calling bpf_get_task_exe_file() would be
+ * analogous to calling get_task_exe_file() outside of BPF program context.
+ *
+ * Return: A referenced pointer to the exe_file associated with the mm_struct
+ * nested in the supplied *task*, or NULL.
+ */
+__bpf_kfunc struct file *bpf_get_task_exe_file(struct task_struct *task)
+{
+ return get_task_exe_file(task);
+}
+
+/**
+ * bpf_get_mm_exe_file - get a reference on the exe_file for the supplied
+ * mm_struct.
+ * @mm: mm_struct of which the exe_file to get a reference on
+ *
+ * Get a reference on the exe_file associated with the supplied *mm*. A
+ * reference on a file pointer acquired by this kfunc must be released using
+ * bpf_put_file(). Internally, this kfunc leans on get_mm_exe_file(), such that
+ * calling bpf_get_mm_exe_file() would be analogous to calling get_mm_exe_file()
+ * outside of BPF program context.
+ *
+ * Return: A referenced file pointer to the exe_file for the supplied *mm*, or
+ * NULL.
+ */
+__bpf_kfunc struct file *bpf_get_mm_exe_file(struct mm_struct *mm)
+{
+ return get_mm_exe_file(mm);
+}
+
+/**
+ * bpf_put_file - put a reference on the supplied file
+ * @f: file of which to put a reference on
+ *
+ * Put a reference on the supplied *f*.
+ */
+__bpf_kfunc void bpf_put_file(struct file *f)
+{
+ fput(f);
+}
+
__bpf_kfunc_end_defs();
BTF_KFUNCS_START(lsm_kfunc_set_ids)
BTF_ID_FLAGS(func, bpf_get_file_xattr, KF_SLEEPABLE | KF_TRUSTED_ARGS)
BTF_ID_FLAGS(func, bpf_task_mm_grab, KF_ACQUIRE | KF_TRUSTED_ARGS | KF_RET_NULL);
BTF_ID_FLAGS(func, bpf_mm_drop, KF_RELEASE);
+BTF_ID_FLAGS(func, bpf_get_task_exe_file,
+ KF_ACQUIRE | KF_TRUSTED_ARGS | KF_RET_NULL)
+BTF_ID_FLAGS(func, bpf_get_mm_exe_file,
+ KF_ACQUIRE | KF_TRUSTED_ARGS | KF_RET_NULL)
+BTF_ID_FLAGS(func, bpf_put_file, KF_RELEASE | KF_SLEEPABLE)
BTF_KFUNCS_END(lsm_kfunc_set_ids)
static int bpf_lsm_kfunc_filter(const struct bpf_prog *prog, u32 kfunc_id)
--
2.44.0.278.ge034bb2e1d-goog
/M
next prev parent reply other threads:[~2024-03-06 7:40 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-06 7:39 [PATCH v2 bpf-next 0/9] add new acquire/release BPF kfuncs Matt Bobrowski
2024-03-06 7:39 ` [PATCH v2 bpf-next 1/9] bpf: rename fs_kfunc_set_ids to lsm_kfunc_set_ids Matt Bobrowski
2024-03-06 7:39 ` [PATCH v2 bpf-next 2/9] bpf: add new acquire/release BPF kfuncs for mm_struct Matt Bobrowski
2024-03-06 11:50 ` Christian Brauner
2024-03-06 7:39 ` [PATCH v2 bpf-next 3/9] bpf/selftests: add selftests for mm_struct acquire/release BPF kfuncs Matt Bobrowski
2024-03-06 7:40 ` Matt Bobrowski [this message]
2024-03-06 11:31 ` [PATCH v2 bpf-next 4/9] bpf: add new acquire/release based BPF kfuncs for exe_file Christian Brauner
2024-03-06 7:40 ` [PATCH v2 bpf-next 5/9] bpf/selftests: add selftests for exe_file acquire/release BPF kfuncs Matt Bobrowski
2024-03-06 7:40 ` [PATCH v2 bpf-next 6/9] bpf: add acquire/release based BPF kfuncs for fs_struct's paths Matt Bobrowski
2024-03-06 11:47 ` Christian Brauner
2024-03-06 7:40 ` [PATCH v2 bpf-next 7/9] bpf/selftests: add selftests for root/pwd path based BPF kfuncs Matt Bobrowski
2024-03-06 7:40 ` [PATCH v2 bpf-next 9/9] bpf/selftests: adapt selftests test_d_path for BPF kfunc bpf_path_d_path() Matt Bobrowski
2024-03-06 7:40 ` [PATCH v2 bpf-next 8/9] bpf: add trusted d_path() based " Matt Bobrowski
2024-03-06 11:21 ` [PATCH v2 bpf-next 0/9] add new acquire/release BPF kfuncs Christian Brauner
2024-03-06 12:13 ` Christian Brauner
2024-03-06 21:44 ` Paul Moore
2024-03-07 4:05 ` Alexei Starovoitov
2024-03-07 9:54 ` Christian Brauner
2024-03-07 20:50 ` Paul Moore
2024-03-08 3:25 ` Alexei Starovoitov
2024-03-08 10:58 ` Christian Brauner
2024-03-08 3:11 ` Alexei Starovoitov
2024-03-08 10:35 ` Christian Brauner
2024-03-09 1:23 ` Alexei Starovoitov
2024-03-11 12:00 ` Christian Brauner
2024-03-12 17:06 ` Matt Bobrowski
2024-03-12 20:11 ` Matt Bobrowski
2024-03-18 13:24 ` Christian Brauner
2024-03-13 21:05 ` Alexei Starovoitov
2024-03-18 13:14 ` Christian Brauner
2024-03-27 21:41 ` Alexei Starovoitov
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=6a5d425e52eb4d8f7539e841494eac36688ab0da.1709675979.git.mattbobrowski@google.com \
--to=mattbobrowski@google.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=daniel@iogearbox.net \
--cc=jannh@google.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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;
as well as URLs for NNTP newsgroup(s).