From: Kumar Kartikeya Dwivedi <memxor@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Yonghong Song <yhs@fb.com>,
bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
John Fastabend <john.fastabend@gmail.com>,
kernel-team@fb.com, Martin KaFai Lau <martin.lau@kernel.org>,
Namhyung Kim <namhyung@kernel.org>
Subject: Re: [RFC PATCH bpf-next 2/3] bpf: Implement bpf_get_kern_btf_id() kfunc
Date: Wed, 16 Nov 2022 01:35:41 +0530 [thread overview]
Message-ID: <20221115200541.bm7xhdurhpxuv54u@apollo> (raw)
In-Reply-To: <20221115194308.ej5lwd2jo6ulebut@MacBook-Pro-5.local.dhcp.thefacebook.com>
On Wed, Nov 16, 2022 at 01:13:08AM IST, Alexei Starovoitov wrote:
> On Mon, Nov 14, 2022 at 08:23:39AM -0800, Yonghong Song wrote:
> > The signature of bpf_get_kern_btf_id() function looks like
> > void *bpf_get_kern_btf_id(obj, expected_btf_id)
> > The obj has a pointer type. The expected_btf_id is 0 or
> > a btf id to be returned by the kfunc. The function
> > currently supports two kinds of obj:
> > - obj: ptr_to_ctx, expected_btf_id: 0
> > return the expected kernel ctx btf id
> > - obj: ptr to char/unsigned char, expected_btf_id: a struct btf id
> > return expected_btf_id
> > The second case looks like a type casting, e.g., in kernel we have
> > #define skb_shinfo(SKB) ((struct skb_shared_info *)(skb_end_pointer(SKB)))
> > bpf program can get a skb_shared_info btf id ptr with bpf_get_kern_btf_id()
> > kfunc.
>
> Kumar has proposed
> bpf_rdonly_cast(any_64bit_value, btf_id) -> PTR_TO_BTF_ID | PTR_UNTRUSTED.
> The idea of bpf_get_kern_btf_id(ctx) looks complementary.
> The bpf_get_kern_btf_id name is too specific imo.
> How about two kfuncs:
>
> bpf_cast_to_kern_ctx(ctx) -> ptr_to_btf_id | ptr_trusted
> bpf_rdonly_cast(any_scalar, btf_id) -> ptr_to_btf_id | ptr_untrusted
>
> ptr_trusted flag will have semantics as discsused with David and Kumar in:
> https://lore.kernel.org/bpf/CAADnVQ+KZcFZdC=W_qZ3kam9yAjORtpN-9+Ptg_Whj-gRxCZNQ@mail.gmail.com/
>
> The verifier knows how to cast safe pointer 'ctx' to kernel 'mirror' structure.
> No need for additional btf_id argument.
> We can express it as ptr_to_btf_id | ptr_trusted and safely pass to kfuncs.
> bpf_rdonly_cast() can accept any 64-bit value.
> There is no need to limit it to 'char *' arg. Since it's ptr_to_btf_id | ptr_untrusted
> it cannot be passed to kfuncs and only rdonly acccess is allowed.
> Both kfuncs need to be cap_perfmon gated, of course.
> Thoughts?
Here is the PoC I wrote when we discussed this:
It still uses bpf_unsafe_cast naming, but that was before Alexei suggested the
bpf_rdonly_cast name.
https://github.com/kkdwivedi/linux/commits/unsafe-cast (see the 2 latest commits)
The selftest showcases how it will be useful.
next prev parent reply other threads:[~2022-11-15 20:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-14 16:23 [RFC PATCH bpf-next 0/3] bpf: Implement bpf_get_kern_btf_id() kfunc Yonghong Song
2022-11-14 16:23 ` [RFC PATCH bpf-next 1/3] bpf: Add support for kfunc set with generic btf_ids Yonghong Song
2022-11-14 16:23 ` [RFC PATCH bpf-next 2/3] bpf: Implement bpf_get_kern_btf_id() kfunc Yonghong Song
2022-11-15 19:43 ` Alexei Starovoitov
2022-11-15 20:05 ` Kumar Kartikeya Dwivedi [this message]
2022-11-15 20:26 ` Yonghong Song
2022-11-17 18:24 ` Kumar Kartikeya Dwivedi
2022-11-17 22:52 ` Yonghong Song
2022-11-17 23:01 ` Kumar Kartikeya Dwivedi
2022-11-17 23:13 ` Yonghong Song
2022-11-14 16:23 ` [RFC PATCH bpf-next 3/3] bpf: Add bpf_get_kern_btf_id() tests Yonghong Song
2022-11-15 16:30 ` [RFC PATCH bpf-next 0/3] bpf: Implement bpf_get_kern_btf_id() kfunc Toke Høiland-Jørgensen
2022-11-15 19:53 ` Yonghong Song
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=20221115200541.bm7xhdurhpxuv54u@apollo \
--to=memxor@gmail.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=john.fastabend@gmail.com \
--cc=kernel-team@fb.com \
--cc=martin.lau@kernel.org \
--cc=namhyung@kernel.org \
--cc=yhs@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