From: Song Liu <songliubraving@meta.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Song Liu <song@kernel.org>, bpf <bpf@vger.kernel.org>,
Linux-Fsdevel <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Kernel Team <kernel-team@meta.com>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <martin.lau@linux.dev>,
"brauner@kernel.org" <brauner@kernel.org>,
Jan Kara <jack@suse.cz>, KP Singh <kpsingh@kernel.org>,
"mattbobrowski@google.com" <mattbobrowski@google.com>
Subject: Re: [PATCH bpf-next 1/2] bpf: Add kfunc bpf_get_dentry_xattr() to read xattr from dentry
Date: Fri, 26 Jul 2024 07:01:39 +0000 [thread overview]
Message-ID: <B0E4F345-9958-44C2-9985-96F77F0DEF0F@fb.com> (raw)
In-Reply-To: <20240726053430.GB99483@ZenIV>
Hi Al,
Thanks for your quick reply.
> On Jul 25, 2024, at 10:34 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Thu, Jul 25, 2024 at 04:47:05PM -0700, Song Liu wrote:
>
>> +__bpf_kfunc struct dentry *bpf_file_dentry(const struct file *file)
>> +{
>> + /* file_dentry() does not hold reference to the dentry. We add a
>> + * dget() here so that we can add KF_ACQUIRE flag to
>> + * bpf_file_dentry().
>> + */
>> + return dget(file_dentry(file));
>> +}
>> +
>> +__bpf_kfunc struct dentry *bpf_dget_parent(struct dentry *dentry)
>> +{
>> + return dget_parent(dentry);
>> +}
>> +
>> +__bpf_kfunc void bpf_dput(struct dentry *dentry)
>> +{
>> + return dput(dentry);
>> +}
>
> If you keep a file reference, why bother grabbing dentry one?
> If not, you have a very bad trouble if that opened file is the only
> thing that keeps the filesystem busy.
Yes, we keep a file reference for the duration of the BPF program.
Therefore, it is technically not necessary to grab a dentry one.
However, we grab a dentry reference to make the dentry pointer
returned by bpf_file_dentry() a trusted pointer from BPF verifier's
POV, so that these kfuncs are more robust.
The following explanation is a bit long. Please let me know if it
turns out confusing.
==== What is trusted pointer? ====
Trusted point is the mechanism to make sure bpf kfuncs are
called with valid pointer. The BPF verifier requires certain BPF
kfuncs (helpers) are called with trusted pointers. A pointer is
trusted if one of the following two is true:
1. The pointer is passed directly by the tracepoint/kprobe, i.e.,
no pointer walking, no non-zero offset. For example,
int bpf_security_file_open(struct file *file) /* file is trusted */
{
/* mapping is not trusted */
struct address_space *mapping = file->f_mapping;
/* file2 is not trusted */
struct file *file2 = file + 1;
}
2. The pointer is returned by a kfunc with KF_ACQUIRE. This pointer
has to be released by a kfunc with KF_RELEASE. KF_ACQUIRE and
KF_RELEASE kfuncs are like any _get() _put() pairs.
==== bpf_dget_parent and bpf_dput ====
In this case, bpf_dget_parent() is a KF_ACQUIRE kfunc and
bpf_dput() is a KF_RELEASE function. They are just like regular
_get() _put() functions.
The BPF verifier makes sure pointers acquired by bpf_dget_parent()
is always released by bpf_dput() before the BPF program returns.
For example, in the following BPF program:
xxxx(struct dentry *d)
{
struct dentry *parent = bpf_dget_parent(d);
/* main logic */
bpf_dput(parent);
}
If the bpf_dput() call is missing, the verifier will not allow
the program to load.
==== More on kfunc safety ====
Trusted point makes kfunc calls safe. In this case, we want
bpf_get_dentry_xattr() to only take trusted dentry pointer.
For example, in the security_inode_listxattr LSM hook:
bpf_security_inode_listxattr(struct dentry *dentry)
{
/* This is allowed, dentry is an input and thus
* is trusted
*/
bpf_get_dentry_xattr(dentry);
/* This is not allowed, as dentry->d_parent is
* not trusted
*/
bpf_get_dentry_xattr(dentry->d_parent);
/* This is allowed, as bpf_dget_parent() holds
* a reference to d_parent, and returns a trusted
* pointer
*/
struct dentry *parent = bpf_dget_parent(dentry);
/* The following is needed, as we need the release
* parent pointer. If this line is missing, this
* program cannot pass BPF verifier.
*/
bpf_dput(parent);
}
==== bpf_file_dentry ====
In this use case, we want to get from file pointer, such as
LSM hook security_file_open() to the dentry and thus walk the
directory tree. However, security_file_open() does not pass
in a dentry pointer, and file->f_path.dentry is not a trusted
pointer. There are two ways to get a trusted dentry pointer
from a file pointer:
1. As what we do here, use bpf_file_dentry() to hold a
reference on file->f_path.dentry and return a trusted
pointer.
2. Give the verifier special knowledge that if file pointer
is trusted, file->f_path.dentry is also trusted. This
can be achieve with the following macros:
BTF_TYPE_SAFE_TRUSTED
BTF_TYPE_SAFE_RCU
BTF_TYPE_SAFE_RCU_OR_NULL.
Using the second method here requires a little more work in the
BPF verifier, as dentry is not a simple pointer in struct file,
but f_path.dentry. Therefore, I chose current approach that
bpf_file_dentry() holds a reference on dentry pointer, and the
pointer has to be released with bpf_dput().
For more details about trusted pointers in kfuncs, please refer to
Documentation/bpf/kfuncs.rst.
Does this answer your question?
Thanks,
Song
> It's almost certainly a wrong interface; please, explain what
> exactly are you trying to do here.
next prev parent reply other threads:[~2024-07-26 7:01 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-25 23:47 [PATCH bpf-next 0/2] Add kfuncs to support reading xattr from dentry Song Liu
2024-07-25 23:47 ` [PATCH bpf-next 1/2] bpf: Add kfunc bpf_get_dentry_xattr() to read " Song Liu
2024-07-26 5:34 ` Al Viro
2024-07-26 7:01 ` Song Liu [this message]
2024-07-25 23:47 ` [PATCH bpf-next 2/2] selftests/bpf: Add tests for bpf_get_dentry_xattr Song Liu
2024-07-26 7:06 ` Christian Brauner
2024-07-26 9:19 ` Song Liu
2024-07-26 11:51 ` Christian Brauner
2024-07-26 19:43 ` Song Liu
2024-07-29 13:46 ` Christian Brauner
2024-07-30 5:58 ` Song Liu
2024-07-30 8:59 ` Christian Brauner
2024-08-19 7:18 ` Song Liu
2024-08-19 11:16 ` Christian Brauner
2024-08-19 13:12 ` Mickaël Salaün
2024-08-19 20:35 ` Song Liu
2024-08-20 12:45 ` Mickaël Salaün
2024-08-20 17:42 ` Song Liu
2024-08-20 21:11 ` Paul Moore
2024-08-21 3:43 ` Song Liu
2024-08-23 10:38 ` Mickaël Salaün
2024-08-19 20:25 ` Song Liu
2024-08-20 5:42 ` Song Liu
2024-08-20 6:29 ` Al Viro
2024-08-20 7:23 ` Song Liu
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=B0E4F345-9958-44C2-9985-96F77F0DEF0F@fb.com \
--to=songliubraving@meta.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=jack@suse.cz \
--cc=kernel-team@meta.com \
--cc=kpsingh@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mattbobrowski@google.com \
--cc=song@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox