| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAEf4BzZMj0sPisgUZ+3qKvqaAxfzzRNHZTpoR-zuDXvKcY3URQ@mail.gmail.com>
Date: Fri, 11 Sep 2020 14:10:34 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Toke Høiland-Jørgensen <toke@...hat.com>
Cc: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
Andrii Nakryiko <andriin@...com>,
John Fastabend <john.fastabend@...il.com>,
Jiri Olsa <jolsa@...hat.com>,
Eelco Chaudron <echaudro@...hat.com>,
KP Singh <kpsingh@...omium.org>,
Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH RESEND bpf-next v3 4/9] bpf: support attaching freplace
programs to multiple attach points
On Fri, Sep 11, 2020 at 3:01 AM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> From: Toke Høiland-Jørgensen <toke@...hat.com>
>
> This enables support for attaching freplace programs to multiple attach
> points. It does this by amending UAPI for bpf_raw_tracepoint_open with a
> target prog fd and btf ID pair that can be used to supply the new
> attachment point. The target must be compatible with the target that was
> supplied at program load time.
>
> The implementation reuses the checks that were factored out of
> check_attach_btf_id() to ensure compatibility between the BTF types of the
> old and new attachment. If these match, a new bpf_tracing_link will be
> created for the new attach target, allowing multiple attachments to
> co-exist simultaneously.
>
> The code could theoretically support multiple-attach of other types of
> tracing programs as well, but since I don't have a use case for any of
> those, the bpf_tracing_prog_attach() function will reject new targets for
> anything other than PROG_TYPE_EXT programs.
>
> Signed-off-by: Toke Høiland-Jørgensen <toke@...hat.com>
> ---
It feels like using a semi-constructed bpf_tracing_link inside
prog->aux->tgt_link is just an unnecessary complication, after reading
this and previous patches. Seems more straightforward and simpler to
store tgt_attach_type/tgt_prog_type (permanently) and
tgt_prog/tgt_trampoline (until first attachment) in prog->aux and then
properly create bpf_link on attach.
> include/linux/bpf.h | 3 +
> include/uapi/linux/bpf.h | 6 ++-
> kernel/bpf/syscall.c | 96 +++++++++++++++++++++++++++++++++++++++-------
> kernel/bpf/verifier.c | 9 ++++
> 4 files changed, 97 insertions(+), 17 deletions(-)
>
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 722c60f1c1fc..c6b856b2d296 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -753,6 +753,9 @@ struct bpf_prog_aux {
> struct hlist_node tramp_hlist;
> /* BTF_KIND_FUNC_PROTO for valid attach_btf_id */
> const struct btf_type *attach_func_proto;
> + /* target BPF prog types for trace programs */
> + enum bpf_prog_type tgt_prog_type;
> + enum bpf_attach_type tgt_attach_type;
> /* function name for valid attach_btf_id */
> const char *attach_func_name;
> struct bpf_prog **func;
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 90359cab501d..0885ab6ac8d9 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -595,8 +595,10 @@ union bpf_attr {
> } query;
>
> struct { /* anonymous struct used by BPF_RAW_TRACEPOINT_OPEN command */
> - __u64 name;
> - __u32 prog_fd;
> + __u64 name;
> + __u32 prog_fd;
> + __u32 tgt_prog_fd;
> + __u32 tgt_btf_id;
> } raw_tracepoint;
rant: any chance of putting this into LINK_CREATE instead of extending
very unfortunately named RAW_TRACEPOINT_OPEN?
>
> struct { /* anonymous struct for BPF_BTF_LOAD */
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 2d238aa8962e..7b1da5f063eb 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -4,6 +4,7 @@
> #include <linux/bpf.h>
> #include <linux/bpf_trace.h>
> #include <linux/bpf_lirc.h>
> +#include <linux/bpf_verifier.h>
> #include <linux/btf.h>
> #include <linux/syscalls.h>
> #include <linux/slab.h>
> @@ -2582,10 +2583,16 @@ static struct bpf_tracing_link *bpf_tracing_link_create(struct bpf_prog *prog,
> return link;
> }
>
> -static int bpf_tracing_prog_attach(struct bpf_prog *prog)
> +static int bpf_tracing_prog_attach(struct bpf_prog *prog,
> + int tgt_prog_fd,
> + u32 btf_id)
> {
> - struct bpf_tracing_link *link, *olink;
> struct bpf_link_primer link_primer;
> + struct bpf_prog *tgt_prog = NULL;
> + struct bpf_tracing_link *link;
> + struct btf_func_model fmodel;
> + long addr;
> + u64 key;
> int err;
>
> switch (prog->type) {
> @@ -2613,28 +2620,80 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog)
> err = -EINVAL;
> goto out_put_prog;
> }
> + if (tgt_prog_fd) {
> + /* For now we only allow new targets for BPF_PROG_TYPE_EXT */
> + if (prog->type != BPF_PROG_TYPE_EXT ||
> + !btf_id) {
> + err = -EINVAL;
> + goto out_put_prog;
> + }
>
> - link = READ_ONCE(prog->aux->tgt_link);
> - if (!link) {
> - err = -ENOENT;
> + tgt_prog = bpf_prog_get(tgt_prog_fd);
> + if (IS_ERR(tgt_prog)) {
> + err = PTR_ERR(tgt_prog);
> + tgt_prog = NULL;
> + goto out_put_prog;
> + }
> +
> + key = ((u64)tgt_prog->aux->id) << 32 | btf_id;
> + } else if (btf_id) {
> + err = -EINVAL;
> goto out_put_prog;
> }
> - olink = cmpxchg(&prog->aux->tgt_link, link, NULL);
> - if (olink != link) {
> - err = -ENOENT;
> - goto out_put_prog;
> +
> + link = READ_ONCE(prog->aux->tgt_link);
> + if (link) {
> + if (tgt_prog && link->trampoline->key != key) {
I think we need to have a proper locking about this. Imagine two
attaches racing, both read non-NULL tgt_link, one of them proceeds to
cmpxchg, attach, detach, and free link. Then this one wakes up and
tries to access freed memory here. We are coordinating multiple
threads on this, it needs to be locked, at least for simplicity, given
that performance is not critical here.
> + link = NULL;
> + } else {
> + struct bpf_tracing_link *olink;
> +
> + olink = cmpxchg(&prog->aux->tgt_link, link, NULL);
> + if (olink != link) {
> + link = NULL;
> + } else if (tgt_prog) {
> + /* re-using link that already has ref on
> + * tgt_prog, don't take another
> + */
> + bpf_prog_put(tgt_prog);
> + tgt_prog = NULL;
> + }
> + }
> + }
> +
> + if (!link) {
> + if (!tgt_prog) {
> + err = -ENOENT;
> + goto out_put_prog;
> + }
> +
> + err = bpf_check_attach_target(NULL, prog, tgt_prog, btf_id,
> + &fmodel, &addr, NULL, NULL);
> + if (err)
> + goto out_put_prog;
> +
> + link = bpf_tracing_link_create(prog, tgt_prog);
> + if (IS_ERR(link)) {
> + err = PTR_ERR(link);
> + goto out_put_prog;
> + }
> + tgt_prog = NULL;
> +
> + err = bpf_trampoline_get(key, (void *)addr, &fmodel, &link->trampoline);
> + if (err)
> + goto out_put_link;
see previous patch, let's avoid bpf_link_put before bpf_link_settle.
bpf_link_cleanup() is for after priming, otherwise it's just a kfree.
> }
>
> err = bpf_link_prime(&link->link, &link_primer);
> if (err) {
> kfree(link);
> - goto out_put_prog;
> + goto out_put_link;
hm... did you try running this with KASAN? you are freeing link and
then bpf_link_put() on it?
> }
>
> err = bpf_trampoline_link_prog(prog, link->trampoline);
> if (err) {
> bpf_link_cleanup(&link_primer);
> - goto out_put_prog;
> + goto out_put_link;
similarly, you've already bpf_link_cleanup()'d, no need to do extra
bpf_link_put()
> }
>
> /* at this point the link is no longer referenced from struct bpf_prog,
> @@ -2643,8 +2702,12 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog)
> link->link.prog = prog;
>
> return bpf_link_settle(&link_primer);
> +out_put_link:
> + bpf_link_put(&link->link);
> out_put_prog:
> bpf_prog_put(prog);
> + if (tgt_prog)
> + bpf_prog_put(tgt_prog);
> return err;
> }
>
[...]
Powered by blists - more mailing lists