From: Song Liu <songliubraving@meta.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Song Liu <songliubraving@meta.com>, Song Liu <song@kernel.org>,
bpf <bpf@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>,
LSM List <linux-security-module@vger.kernel.org>,
Kernel Team <kernel-team@meta.com>,
Andrii Nakryiko <andrii@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <martin.lau@linux.dev>,
KP Singh <kpsingh@kernel.org>,
Matt Bobrowski <mattbobrowski@google.com>,
Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
"Serge E . Hallyn" <serge@hallyn.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>
Subject: Re: [PATCH v5 bpf-next 4/5] bpf: fs/xattr: Add BPF kfuncs to set and remove xattrs
Date: Thu, 19 Dec 2024 06:59:44 +0000 [thread overview]
Message-ID: <A8A5C206-CEAA-472B-A2BE-99D3E8940159@fb.com> (raw)
In-Reply-To: <CAADnVQ+vgt=LV+3srtGQUtKKc3ohZkaMdHyouXThNmYG2qGoYg@mail.gmail.com>
> On Dec 18, 2024, at 4:17 PM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
[...]
>>> This part is not necessary.
>>> _locked() shouldn't be exposed and it should be an error
>>> if bpf prog attempts to use invalid kfunc.
>>
>> I was implementing this in different way than the solution you and Kumar
>> suggested. Instead of updating this in add_kfunc_call, check_kfunc_call,
>> and fixup_kfunc_call, remap_kfunc_locked_func_id happens before
>> add_kfunc_call. Then, for the rest of the process, the verifier handles
>> _locked version and not _locked version as two different kfuncs. This is
>> why we need the _locked version in bpf_fs_kfunc_set_ids. I personally
>> think this approach is a lot cleaner.
>
> I see. Blind rewrite in add_kfunc_call() looks simpler,
> but allowing progs call _locked() version directly is not clean.
Agreed.
>
> See specialize_kfunc() as an existing approach that does polymorphism.
>
> _locked() doesn't need to be __bpf_kfunc annotated.
> It can be just like bpf_dynptr_from_skb_rdonly.
I am thinking about a more modular approach. Instead of pushing the
polymorphism logic to verifer.c, we can have each btf_kfunc_id_set
handle the remap of its kfuncs. Specifically, we can extend
btf_kfunc_id_set as:
typedef u32 (*btf_kfunc_remap_t)(const struct bpf_prog *prog, u32 kfunc_id);
struct btf_kfunc_id_set {
struct module *owner;
struct btf_id_set8 *set;
/* hidden_set contains kfuncs that are not marked as kfunc in
* vmlinux.h. These kfuncs are usually a variation of a kfunc
* in @set.
*/
struct btf_id_set8 *hidden_set;
btf_kfunc_filter_t filter;
/* @remap method matches kfuncs in @set to proper version in
* @hidden_set.
*/
btf_kfunc_remap_t remap;
};
In this case, not_locked version of kfuncs will be added to @set;
while _locked kfuncs will be added to @hidden_set. @hidden_set
will not be exposed in vmlinux.h. Then the new remap method is
used to map not_locked kfuncs to _locked kfuncs for inode-locked
context.
We can also move bpf_dynptr_from_skb_rdonly to this model, and
simplify specialize_kfunc().
I will send patch for this version for review.
Thanks,
Song
next prev parent reply other threads:[~2024-12-19 6:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-18 4:47 [PATCH v5 bpf-next 0/5] Enable writing xattr from BPF programs Song Liu
2024-12-18 4:47 ` [PATCH v5 bpf-next 1/5] fs/xattr: bpf: Introduce security.bpf. xattr name prefix Song Liu
2024-12-18 4:47 ` [PATCH v5 bpf-next 2/5] selftests/bpf: Extend test fs_kfuncs to cover security.bpf. xattr names Song Liu
2024-12-18 4:47 ` [PATCH v5 bpf-next 3/5] bpf: lsm: Add two more sleepable hooks Song Liu
2024-12-18 4:47 ` [PATCH v5 bpf-next 4/5] bpf: fs/xattr: Add BPF kfuncs to set and remove xattrs Song Liu
2024-12-18 21:20 ` Alexei Starovoitov
2024-12-18 21:47 ` Song Liu
2024-12-18 22:10 ` Song Liu
2024-12-19 0:17 ` Alexei Starovoitov
2024-12-19 6:59 ` Song Liu [this message]
2024-12-18 4:47 ` [PATCH v5 bpf-next 5/5] selftests/bpf: Test kfuncs that set and remove xattr from BPF programs 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=A8A5C206-CEAA-472B-A2BE-99D3E8940159@fb.com \
--to=songliubraving@meta.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=jmorris@namei.org \
--cc=kernel-team@meta.com \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mattbobrowski@google.com \
--cc=memxor@gmail.com \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
--cc=song@kernel.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).