From: Florent Revest <revest@chromium.org>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
KP Singh <kpsingh@chromium.org>,
open list <linux-kernel@vger.kernel.org>,
KP Singh <kpsingh@kernel.org>
Subject: Re: [PATCH bpf-next v6 2/5] bpf: Expose bpf_get_socket_cookie to tracing programs
Date: Sat, 30 Jan 2021 12:45:29 +0100 [thread overview]
Message-ID: <CABRcYm+cNW5A_=5qsKRuX7feB--xyTu3vPSRfzZcuFahzwuxhw@mail.gmail.com> (raw)
In-Reply-To: <37730136-2c33-589c-a749-4221b60b9751@iogearbox.net>
On Fri, Jan 29, 2021 at 1:49 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 1/29/21 11:57 AM, Daniel Borkmann wrote:
> > On 1/27/21 10:01 PM, Andrii Nakryiko wrote:
> >> On Tue, Jan 26, 2021 at 10:36 AM Florent Revest <revest@chromium.org> wrote:
> >>>
> >>> This needs a new helper that:
> >>> - can work in a sleepable context (using sock_gen_cookie)
> >>> - takes a struct sock pointer and checks that it's not NULL
> >>>
> >>> Signed-off-by: Florent Revest <revest@chromium.org>
> >>> Acked-by: KP Singh <kpsingh@kernel.org>
> >>> ---
> >>> include/linux/bpf.h | 1 +
> >>> include/uapi/linux/bpf.h | 8 ++++++++
> >>> kernel/trace/bpf_trace.c | 2 ++
> >>> net/core/filter.c | 12 ++++++++++++
> >>> tools/include/uapi/linux/bpf.h | 8 ++++++++
> >>> 5 files changed, 31 insertions(+)
> >>>
> >>> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> >>> index 1aac2af12fed..26219465e1f7 100644
> >>> --- a/include/linux/bpf.h
> >>> +++ b/include/linux/bpf.h
> >>> @@ -1874,6 +1874,7 @@ extern const struct bpf_func_proto bpf_per_cpu_ptr_proto;
> >>> extern const struct bpf_func_proto bpf_this_cpu_ptr_proto;
> >>> extern const struct bpf_func_proto bpf_ktime_get_coarse_ns_proto;
> >>> extern const struct bpf_func_proto bpf_sock_from_file_proto;
> >>> +extern const struct bpf_func_proto bpf_get_socket_ptr_cookie_proto;
> >>>
> >>> const struct bpf_func_proto *bpf_tracing_func_proto(
> >>> enum bpf_func_id func_id, const struct bpf_prog *prog);
> >>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> >>> index 0b735c2729b2..5855c398d685 100644
> >>> --- a/include/uapi/linux/bpf.h
> >>> +++ b/include/uapi/linux/bpf.h
> >>> @@ -1673,6 +1673,14 @@ union bpf_attr {
> >>> * Return
> >>> * A 8-byte long unique number.
> >>> *
> >>> + * u64 bpf_get_socket_cookie(void *sk)
> >>
> >> should the type be `struct sock *` then?
> >
> > Checking libbpf's generated bpf_helper_defs.h it generates:
> >
> > /*
> > * bpf_get_socket_cookie
> > *
> > * If the **struct sk_buff** pointed by *skb* has a known socket,
> > * retrieve the cookie (generated by the kernel) of this socket.
> > * If no cookie has been set yet, generate a new cookie. Once
> > * generated, the socket cookie remains stable for the life of the
> > * socket. This helper can be useful for monitoring per socket
> > * networking traffic statistics as it provides a global socket
> > * identifier that can be assumed unique.
> > *
> > * Returns
> > * A 8-byte long non-decreasing number on success, or 0 if the
> > * socket field is missing inside *skb*.
> > */
> > static __u64 (*bpf_get_socket_cookie)(void *ctx) = (void *) 46;
> >
> > So in terms of helper comment it's picking up the description from the
> > `u64 bpf_get_socket_cookie(struct sk_buff *skb)` signature. With that
> > in mind it would likely make sense to add the actual `struct sock *` type
> > to the comment to make it more clear in here.
>
> One thought that still came to mind when looking over the series again, do
> we need to blacklist certain functions from bpf_get_socket_cookie() under
> tracing e.g. when attaching to, say fexit? For example, if sk_prot_free()
> would be temporary uninlined/exported for testing and bpf_get_socket_cookie()
> was invoked from a prog upon fexit where sock was already passed back to
> allocator, I presume there's risk of mem corruption, no?
Mh, this is interesting. I can try to add a deny list in v7 but I'm
not sure whether I'll be able to catch them all. I'm assuming that
__sk_destruct, sk_destruct, __sk_free, sk_free would be other
problematic functions but potentially there would be more.
next prev parent reply other threads:[~2021-01-30 11:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-26 18:35 [PATCH bpf-next v6 1/5] bpf: Be less specific about socket cookies guarantees Florent Revest
2021-01-26 18:35 ` [PATCH bpf-next v6 2/5] bpf: Expose bpf_get_socket_cookie to tracing programs Florent Revest
2021-01-27 21:01 ` Andrii Nakryiko
2021-01-30 11:35 ` Florent Revest
[not found] ` <4a8ceab1-6eef-9fda-0502-5a0550f53ddc@iogearbox.net>
[not found] ` <37730136-2c33-589c-a749-4221b60b9751@iogearbox.net>
2021-01-30 11:45 ` Florent Revest [this message]
2021-02-01 22:32 ` Daniel Borkmann
2021-02-01 22:37 ` Alexei Starovoitov
2021-02-10 11:10 ` Florent Revest
2021-01-26 18:35 ` [PATCH bpf-next v6 3/5] selftests/bpf: Integrate the socket_cookie test to test_progs Florent Revest
2021-01-27 20:58 ` Andrii Nakryiko
2021-01-26 18:35 ` [PATCH bpf-next v6 4/5] selftests/bpf: Use vmlinux.h in socket_cookie_prog.c Florent Revest
2021-01-27 20:57 ` Andrii Nakryiko
2021-01-26 18:35 ` [PATCH bpf-next v6 5/5] selftests/bpf: Add a selftest for the tracing bpf_get_socket_cookie Florent Revest
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='CABRcYm+cNW5A_=5qsKRuX7feB--xyTu3vPSRfzZcuFahzwuxhw@mail.gmail.com' \
--to=revest@chromium.org \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kpsingh@chromium.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.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).