From patchwork Sat Dec 2 19:15:47 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dmitry Dolgov <9erthalion6@gmail.com> X-Patchwork-Id: 13477034 X-Patchwork-Delegate: bpf@iogearbox.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BjaH4eQH" Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 69E14125 for ; Sat, 2 Dec 2023 11:19:47 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-9fa45e75ed9so465007666b.1 for ; Sat, 02 Dec 2023 11:19:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701544785; x=1702149585; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=CVnD9IBKgeFXP1N/4EisJqwdjkIdWjmpXDkOaU1l2H0=; b=BjaH4eQHgwykQaCIrUp7JJdBLEyVwWOiqbCi9YFduGND0fKrr4fvqVG4V2UKMX9dZZ Rp8uNNpMjVa90GJWFMMOfYQGOGsYeldHByy+nnmT6kXSIP+lNJBUZKKrO4sTkucEu1fa iHev37Iid4BNdH+yQ/YkCMxeJmSZpDBslGndj0Fzm6l6IkrlaCibKDaUW2ojEChVxW4O qlIkFGH8WwOMP399ry2a7ITZkrISIvT00Dy5RB6+dwj14NRlTyFcZhwMXn1pO/NHb0RL W+jzH4mKIAHAhhs10hUU/7CPN+9DOL0dPUc7YiURTQXmvHifijHyr8klepO5QAZqoQQA oHew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701544785; x=1702149585; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CVnD9IBKgeFXP1N/4EisJqwdjkIdWjmpXDkOaU1l2H0=; b=JFsWYXKBB7jGyzVB5YF2IVlRFNSH6wthfxCCgTp80cmZ90H4nMsxt+9MXb139AH1Vc kPijmYqEVDbPtB5h33lBHoTdyJnfhuScSlRp+tXKklMYwq0LXVf2JmzyoSYzCmAGqM+H BKenRgXluRBF06tMx5eDP0EOtKOm2+4d5ybTLQsPokfiydVHzOOJcj0NtiDb31+8CtA/ SBCDY53xOUOoVxy2CIz2bY3bgLF2z+2/D2j/ORwrfW2Xww1JINzAt7QzvcQwVlbc+0fu dm50XB3M7F8fRNPdOh/fp7qV8Z21QsZw9/mG7y+ZfmnFsF5+GL8UdHK9Ondn06KNPN0z MI2Q== X-Gm-Message-State: AOJu0YyPHb+eBnfWFUizywUG5DWL9srpfJUuOb+JPFYg+kjsVytuNiWZ QOufLYJpBVY8Hlt9awJCg95aCg1scHzkIw== X-Google-Smtp-Source: AGHT+IGdO+iRzWWumSEC+qjIegMz38ZOfYsI3AGMCOWLKkWpKeeCZCjwgahwhUnzsa0p6udFEbauyg== X-Received: by 2002:a17:906:20d9:b0:9d4:2080:61dc with SMTP id c25-20020a17090620d900b009d4208061dcmr2083865ejc.22.1701544785350; Sat, 02 Dec 2023 11:19:45 -0800 (PST) Received: from localhost.localdomain ([2a00:20:6008:6fb9:fa16:54ff:fe6e:2940]) by smtp.gmail.com with ESMTPSA id i23-20020a170906115700b00a18ed83ce42sm3127814eja.15.2023.12.02.11.19.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Dec 2023 11:19:45 -0800 (PST) From: Dmitrii Dolgov <9erthalion6@gmail.com> To: bpf@vger.kernel.org Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev, dan.carpenter@linaro.org, olsajiri@gmail.com, asavkov@redhat.com, Dmitrii Dolgov <9erthalion6@gmail.com> Subject: [PATCH bpf-next v6 1/4] bpf: Relax tracing prog recursive attach rules Date: Sat, 2 Dec 2023 20:15:47 +0100 Message-ID: <20231202191556.30997-2-9erthalion6@gmail.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20231202191556.30997-1-9erthalion6@gmail.com> References: <20231202191556.30997-1-9erthalion6@gmail.com> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: bpf@iogearbox.net Currently, it's not allowed to attach an fentry/fexit prog to another one fentry/fexit. At the same time it's not uncommon to see a tracing program with lots of logic in use, and the attachment limitation prevents usage of fentry/fexit for performance analysis (e.g. with "bpftool prog profile" command) in this case. An example could be falcosecurity libs project that uses tp_btf tracing programs. Following the corresponding discussion [1], the reason for that is to avoid tracing progs call cycles without introducing more complex solutions. But currently it seems impossible to load and attach tracing programs in a way that will form such a cycle. The limitation is coming from the fact that attach_prog_fd is specified at the prog load (thus making it impossible to attach to a program loaded after it in this way), as well as tracing progs not implementing link_detach. Replace "no same type" requirement with verification that no more than one level of attachment nesting is allowed. In this way only one fentry/fexit program could be attached to another fentry/fexit to cover profiling use case, and still no cycle could be formed. To implement, add a new field into bpf_prog_aux to track the depth of attachment. [1]: https://lore.kernel.org/bpf/20191108064039.2041889-16-ast@kernel.org/ Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com> --- Previous discussion: https://lore.kernel.org/bpf/20231201154734.8545-1-9erthalion6@gmail.com/ Changes in v6: - Apply nesting level limitation only to tracing programs, otherwise it's possible to apply it in "fentry->extension" case and break it Changes in v5: - Remove follower_cnt and drop unreachable cycle prevention condition - Allow only one level of attachment nesting - Do not display attach_depth in bpftool, as it doesn't make sense anymore Changes in v3: - Fix incorrect decreasing of attach_depth, setting to 0 instead - Place bookkeeping later, to not miss a cleanup if needed - Display attach_depth in bpftool only if the value is not 0 Changes in v2: - Verify tgt_prog is not null - Replace boolean followed with number of followers, to handle multiple progs attaching/detaching include/linux/bpf.h | 1 + include/uapi/linux/bpf.h | 1 + kernel/bpf/syscall.c | 12 ++++++++++++ kernel/bpf/verifier.c | 33 +++++++++++++++++++-------------- tools/include/uapi/linux/bpf.h | 1 + 5 files changed, 34 insertions(+), 14 deletions(-) diff --git a/include/linux/bpf.h b/include/linux/bpf.h index eb447b0a9423..1588e48fe31c 100644 --- a/include/linux/bpf.h +++ b/include/linux/bpf.h @@ -1400,6 +1400,7 @@ struct bpf_prog_aux { u32 real_func_cnt; /* includes hidden progs, only used for JIT and freeing progs */ u32 func_idx; /* 0 for non-func prog, the index in func array for func prog */ u32 attach_btf_id; /* in-kernel BTF type id to attach to */ + u32 attach_depth; /* for tracing prog, level of attachment nesting */ u32 ctx_arg_info_size; u32 max_rdonly_access; u32 max_rdwr_access; diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h index e88746ba7d21..9cf45ad914f1 100644 --- a/include/uapi/linux/bpf.h +++ b/include/uapi/linux/bpf.h @@ -6468,6 +6468,7 @@ struct bpf_prog_info { __u32 verified_insns; __u32 attach_btf_obj_id; __u32 attach_btf_id; + __u32 attach_depth; } __attribute__((aligned(8))); struct bpf_map_info { diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c index 5e43ddd1b83f..9c56b5970d7e 100644 --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -3039,6 +3039,7 @@ static void bpf_tracing_link_release(struct bpf_link *link) bpf_trampoline_put(tr_link->trampoline); + link->prog->aux->attach_depth = 0; /* tgt_prog is NULL if target is a kernel function */ if (tr_link->tgt_prog) bpf_prog_put(tr_link->tgt_prog); @@ -3243,6 +3244,16 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog, goto out_unlock; } + if (tgt_prog) { + /* Bookkeeping for managing the prog attachment chain. If it's a + * tracing program, bump the level, otherwise carry it on. + */ + if (prog->type == BPF_PROG_TYPE_TRACING) + prog->aux->attach_depth = tgt_prog->aux->attach_depth + 1; + else + prog->aux->attach_depth = tgt_prog->aux->attach_depth; + } + link->tgt_prog = tgt_prog; link->trampoline = tr; @@ -4510,6 +4521,7 @@ static int bpf_prog_get_info_by_fd(struct file *file, if (prog->aux->btf) info.btf_id = btf_obj_id(prog->aux->btf); info.attach_btf_id = prog->aux->attach_btf_id; + info.attach_depth = prog->aux->attach_depth; if (attach_btf) info.attach_btf_obj_id = btf_obj_id(attach_btf); diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 8e7b6072e3f4..a3ea2087a6b2 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -20109,6 +20109,11 @@ int bpf_check_attach_target(struct bpf_verifier_log *log, if (tgt_prog) { struct bpf_prog_aux *aux = tgt_prog->aux; + if (aux->attach_depth >= 1) { + bpf_log(log, "Cannot attach with more than one level of nesting\n"); + return -EINVAL; + } + if (bpf_prog_is_dev_bound(prog->aux) && !bpf_prog_dev_bound_match(prog, tgt_prog)) { bpf_log(log, "Target program bound device mismatch"); @@ -20147,10 +20152,11 @@ int bpf_check_attach_target(struct bpf_verifier_log *log, bpf_log(log, "Can attach to only JITed progs\n"); return -EINVAL; } - if (tgt_prog->type == prog->type) { - /* Cannot fentry/fexit another fentry/fexit program. - * Cannot attach program extension to another extension. - * It's ok to attach fentry/fexit to extension program. + if (tgt_prog->type == prog->type && prog_extension) { + /* + * To avoid potential call chain cycles, prevent attaching of a + * program extension to another extension. It's ok to attach + * fentry/fexit to extension program. */ bpf_log(log, "Cannot recursively attach\n"); return -EINVAL; @@ -20163,16 +20169,15 @@ int bpf_check_attach_target(struct bpf_verifier_log *log, * except fentry/fexit. The reason is the following. * The fentry/fexit programs are used for performance * analysis, stats and can be attached to any program - * type except themselves. When extension program is - * replacing XDP function it is necessary to allow - * performance analysis of all functions. Both original - * XDP program and its program extension. Hence - * attaching fentry/fexit to BPF_PROG_TYPE_EXT is - * allowed. If extending of fentry/fexit was allowed it - * would be possible to create long call chain - * fentry->extension->fentry->extension beyond - * reasonable stack size. Hence extending fentry is not - * allowed. + * type. When extension program is replacing XDP function + * it is necessary to allow performance analysis of all + * functions. Both original XDP program and its program + * extension. Hence attaching fentry/fexit to + * BPF_PROG_TYPE_EXT is allowed. If extending of + * fentry/fexit was allowed it would be possible to create + * long call chain fentry->extension->fentry->extension + * beyond reasonable stack size. Hence extending fentry + * is not allowed. */ bpf_log(log, "Cannot extend fentry/fexit\n"); return -EINVAL; diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h index e88746ba7d21..9cf45ad914f1 100644 --- a/tools/include/uapi/linux/bpf.h +++ b/tools/include/uapi/linux/bpf.h @@ -6468,6 +6468,7 @@ struct bpf_prog_info { __u32 verified_insns; __u32 attach_btf_obj_id; __u32 attach_btf_id; + __u32 attach_depth; } __attribute__((aligned(8))); struct bpf_map_info { From patchwork Sat Dec 2 19:15:48 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dmitry Dolgov <9erthalion6@gmail.com> X-Patchwork-Id: 13477035 X-Patchwork-Delegate: bpf@iogearbox.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="kB0nyE3V" Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8FEF8119 for ; Sat, 2 Dec 2023 11:19:48 -0800 (PST) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a184d717de1so449009266b.1 for ; Sat, 02 Dec 2023 11:19:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701544787; x=1702149587; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=+npSO5VrXRYja4620D+qD53+Q+PxXgUKrZXRyIcrmKY=; b=kB0nyE3Vu1mTW+5mA5FOSu3YuRRv/NZ5i5/qj+9FI+PInUp9ExwXUrUKVLsOA/qHqi fQaIOFdARM6R/PWBftdRgypbfmvtxmKkWhMn/lFwQskaYybNq7UNt4DA0GbwSarCodRO ahWBqcS2i2MECFB4vemJgWwnPbNne/2mu6ZXafr/BNsZQpp6cGXmxkkqbwkrNLDhtsph MofZOv96tD5DDYN5GduFyGqn4H5rWZdyBpwMYE0jEyNIQn4VUZ+yoyQloqOqOm+uV3gK VInKtu3A7tdhm/pcwSNNAPElkSz53YpbNJPYPakJ2pNe3scdVonX5/oGSxxQ+6frZ9xh PhBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701544787; x=1702149587; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+npSO5VrXRYja4620D+qD53+Q+PxXgUKrZXRyIcrmKY=; b=DbikEkdcEKcYptmakq5r/OWSM3W4LwR1thC5g2kzyRLrMRJs6NLbNtfx0xJ223rwEV G4ZYbbTadD+Zmdbxr5CGmZG/iZhfLJz579yhzFvPCiZ8a5exZMwh47nZ0AcdM2h35DQg K7tooh2OVo83ag+gWx+4YQrPaTIsXYGpnn8YtMRZPoO/Dk7nqR8fBe5U1+JBbFBG30hX pDPGhENJVxl8yev6Ocns2nC2F0/uYw4FT5yuQliphxc+wOFxAKeHV7kJENwwQPYM6dhr +aNdb9rpC40mfvgCwLuT1YiPCG5cC8x2YRJJAbwWcc6l0IdCSi+gjPSPOjdIaxUkf6Cj argw== X-Gm-Message-State: AOJu0YwnEAFu/R3u8mcY4lzLabjIThyo0hRtk9F3uMvmX5kxVVciBqPm M5Mi0p5F8M7Qjnq+ljIk7drMnhKtgyl2ww== X-Google-Smtp-Source: AGHT+IEP9f37vFAxDuMIl4+2a3iHoajFG93IJ4s+GDB74S0tjA8uchI2cIdOxUKUQbVStLYcsROWdA== X-Received: by 2002:a17:907:2da8:b0:a19:a19b:4232 with SMTP id gt40-20020a1709072da800b00a19a19b4232mr1846516ejc.157.1701544787021; Sat, 02 Dec 2023 11:19:47 -0800 (PST) Received: from localhost.localdomain ([2a00:20:6008:6fb9:fa16:54ff:fe6e:2940]) by smtp.gmail.com with ESMTPSA id i23-20020a170906115700b00a18ed83ce42sm3127814eja.15.2023.12.02.11.19.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Dec 2023 11:19:46 -0800 (PST) From: Dmitrii Dolgov <9erthalion6@gmail.com> To: bpf@vger.kernel.org Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev, dan.carpenter@linaro.org, olsajiri@gmail.com, asavkov@redhat.com, Dmitrii Dolgov <9erthalion6@gmail.com> Subject: [PATCH bpf-next v6 2/4] selftests/bpf: Add test for recursive attachment of tracing progs Date: Sat, 2 Dec 2023 20:15:48 +0100 Message-ID: <20231202191556.30997-3-9erthalion6@gmail.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20231202191556.30997-1-9erthalion6@gmail.com> References: <20231202191556.30997-1-9erthalion6@gmail.com> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: bpf@iogearbox.net Verify the fact that only one fentry prog could be attached to another fentry, building up an attachment chain of limited size. Use existing bpf_testmod as a start of the chain. Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com> --- Changes in v5: - Test only one level of attachment .../bpf/prog_tests/recursive_attach.c | 69 +++++++++++++++++++ .../selftests/bpf/progs/fentry_recursive.c | 19 +++++ .../bpf/progs/fentry_recursive_target.c | 20 ++++++ 3 files changed, 108 insertions(+) create mode 100644 tools/testing/selftests/bpf/prog_tests/recursive_attach.c create mode 100644 tools/testing/selftests/bpf/progs/fentry_recursive.c create mode 100644 tools/testing/selftests/bpf/progs/fentry_recursive_target.c diff --git a/tools/testing/selftests/bpf/prog_tests/recursive_attach.c b/tools/testing/selftests/bpf/prog_tests/recursive_attach.c new file mode 100644 index 000000000000..7248d0661ee9 --- /dev/null +++ b/tools/testing/selftests/bpf/prog_tests/recursive_attach.c @@ -0,0 +1,69 @@ +// SPDX-License-Identifier: GPL-2.0 +/* Copyright (c) 2023 Red Hat, Inc. */ +#include +#include "fentry_recursive.skel.h" +#include "fentry_recursive_target.skel.h" +#include +#include "bpf/libbpf_internal.h" + +/* + * Test following scenarios: + * - attach one fentry progs to another one + * - more than one nesting levels are not allowed + */ +void test_recursive_fentry_attach(void) +{ + struct fentry_recursive_target *target_skel = NULL; + struct fentry_recursive *tracing_chain[2] = {}; + struct bpf_program *prog; + int prev_fd, err; + + target_skel = fentry_recursive_target__open_and_load(); + if (!ASSERT_OK_PTR(target_skel, "fentry_recursive_target__open_and_load")) + goto close_prog; + + /* Create an attachment chain with two fentry progs */ + for (int i = 0; i < 2; i++) { + tracing_chain[i] = fentry_recursive__open(); + if (!ASSERT_OK_PTR(tracing_chain[i], "fentry_recursive__open")) + goto close_prog; + + /* + * The first prog in the chain is going to be attached to the target + * fentry program, the second one to the previous in the chain. + */ + if (i == 0) { + prog = tracing_chain[0]->progs.recursive_attach; + prev_fd = bpf_program__fd(target_skel->progs.test1); + err = bpf_program__set_attach_target(prog, prev_fd, "test1"); + } else { + prog = tracing_chain[i]->progs.recursive_attach; + prev_fd = bpf_program__fd(tracing_chain[i-1]->progs.recursive_attach); + err = bpf_program__set_attach_target(prog, prev_fd, "recursive_attach"); + } + + if (!ASSERT_OK(err, "bpf_program__set_attach_target")) + goto close_prog; + + err = fentry_recursive__load(tracing_chain[i]); + /* The first attach should succeed, the second fail */ + if (i == 0) { + if (!ASSERT_OK(err, "fentry_recursive__load")) + goto close_prog; + + err = fentry_recursive__attach(tracing_chain[i]); + if (!ASSERT_OK(err, "fentry_recursive__attach")) + goto close_prog; + } else { + if (!ASSERT_ERR(err, "fentry_recursive__load")) + goto close_prog; + } + } + +close_prog: + fentry_recursive_target__destroy(target_skel); + for (int i = 0; i < 2; i++) { + if (tracing_chain[i]) + fentry_recursive__destroy(tracing_chain[i]); + } +} diff --git a/tools/testing/selftests/bpf/progs/fentry_recursive.c b/tools/testing/selftests/bpf/progs/fentry_recursive.c new file mode 100644 index 000000000000..1df490230344 --- /dev/null +++ b/tools/testing/selftests/bpf/progs/fentry_recursive.c @@ -0,0 +1,19 @@ +// SPDX-License-Identifier: GPL-2.0 +/* Copyright (c) 2023 Red Hat, Inc. */ +#include +#include +#include + +char _license[] SEC("license") = "GPL"; + +__u64 test1_result = 0; + +/* + * Dummy fentry bpf prog for testing fentry attachment chains + */ +SEC("fentry/XXX") +int BPF_PROG(recursive_attach, int a) +{ + test1_result = a == 1; + return 0; +} diff --git a/tools/testing/selftests/bpf/progs/fentry_recursive_target.c b/tools/testing/selftests/bpf/progs/fentry_recursive_target.c new file mode 100644 index 000000000000..b6fb8ebd598d --- /dev/null +++ b/tools/testing/selftests/bpf/progs/fentry_recursive_target.c @@ -0,0 +1,20 @@ +// SPDX-License-Identifier: GPL-2.0 +/* Copyright (c) 2023 Red Hat, Inc. */ +#include +#include +#include + +char _license[] SEC("license") = "GPL"; + +__u64 test1_result = 0; + +/* + * Dummy fentry bpf prog for testing fentry attachment chains. It's going to be + * a start of the chain. + */ +SEC("fentry/bpf_testmod_fentry_test1") +int BPF_PROG(test1, int a) +{ + test1_result = a == 1; + return 0; +} From patchwork Sat Dec 2 19:15:49 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dmitry Dolgov <9erthalion6@gmail.com> X-Patchwork-Id: 13477036 X-Patchwork-Delegate: bpf@iogearbox.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="EtpCkO7Y" Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 73DF1124 for ; Sat, 2 Dec 2023 11:19:50 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-50be3611794so1142943e87.0 for ; Sat, 02 Dec 2023 11:19:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701544789; x=1702149589; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=pn9w9ZpUJ64xlUNS7Z31Bu8OL5DsLbGaFyGKEHTyr0I=; b=EtpCkO7YEdHnWwvdSVHgQxk1vzSoHfU/x7ETFY5ladJkVpn9ryTgoX61sPRpADuXwP ZoMUiZGaKWgj7XnxsokK9ORbA9TzxNcLUfGgJ0oyMb8vsLQK9gsPMFZ23I+vogLXcaGM m0lYOsd6apBY7shAbVgGft/NWzu065uvOs9rb9IjglHyVPmjsuVjdsjWzT4s78nTIiPP lPqU93htM+rCN08RzNWlPCnmpYndeAjYOCJ5qJAFhRWme9J78VOn8iyST491vScA7JJL T50tTDB9gpWtW5bM21g8bi2OfmC4+galEJvDOeUlCTUTOaSP+DCVN5uxRi6h2VhsV39W mCcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701544789; x=1702149589; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pn9w9ZpUJ64xlUNS7Z31Bu8OL5DsLbGaFyGKEHTyr0I=; b=l7vSEjvJb3UshnsM0OKdivY55qcSgfomGUsT+MB7/7uwDokoqsrZied66lFZONrLUN qk0RE7Ebtw7pUQLHMu1/dyVTa3H+8P0x0/1QJjyR6u18Etf7x0cRNd+3dagsgkhy1r4h wwV9a+cDY3dl+sU8hzUVETQfQqb7zxkkArQFUnyTVcVau1y24BK+ljzV7ODdFwojfUrC WYv14uFmMmBz/yynAtWFA/3TVEOf1PubkMnvP1uY7nt3FayqZm6uvRa2NcIrfg5a5qvX ovLjxIy3qAYVec5uZTsMkYQ50ZtMsd1JgHZAOP8zvjUh5r2qWeFlZQpqfqQPDbYywzlO 5CnQ== X-Gm-Message-State: AOJu0Yy2/LLMUV3vStXFhABZ/X/h0bLsIN1a/i9GNL8o4QXl6Y8VLgLi sPGz3A/mtvHuSfcPl39mSBeR1qUzjKcNRA== X-Google-Smtp-Source: AGHT+IEvFyFoeMm3QIxLp4RZ8dhaGrMmaJAyGfssI7SH1uO7sH/oMUWpZSOX0m7uqxJY8ml14WW/cA== X-Received: by 2002:a19:7517:0:b0:50b:e764:d029 with SMTP id y23-20020a197517000000b0050be764d029mr457659lfe.107.1701544788384; Sat, 02 Dec 2023 11:19:48 -0800 (PST) Received: from localhost.localdomain ([2a00:20:6008:6fb9:fa16:54ff:fe6e:2940]) by smtp.gmail.com with ESMTPSA id i23-20020a170906115700b00a18ed83ce42sm3127814eja.15.2023.12.02.11.19.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Dec 2023 11:19:48 -0800 (PST) From: Dmitrii Dolgov <9erthalion6@gmail.com> To: bpf@vger.kernel.org Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev, dan.carpenter@linaro.org, olsajiri@gmail.com, asavkov@redhat.com, Dmitrii Dolgov <9erthalion6@gmail.com> Subject: [PATCH bpf-next v6 3/4] bpf: Fix re-attachment branch in bpf_tracing_prog_attach Date: Sat, 2 Dec 2023 20:15:49 +0100 Message-ID: <20231202191556.30997-4-9erthalion6@gmail.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20231202191556.30997-1-9erthalion6@gmail.com> References: <20231202191556.30997-1-9erthalion6@gmail.com> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: bpf@iogearbox.net From: Jiri Olsa The following case can cause a crash due to missing attach_btf: 1) load rawtp program 2) load fentry program with rawtp as target_fd 3) create tracing link for fentry program with target_fd = 0 4) repeat 3 In the end we have: - prog->aux->dst_trampoline == NULL - tgt_prog == NULL (because we did not provide target_fd to link_create) - prog->aux->attach_btf == NULL (the program was loaded with attach_prog_fd=X) - the program was loaded for tgt_prog but we have no way to find out which one BUG: kernel NULL pointer dereference, address: 0000000000000058 Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x15b/0x430 ? fixup_exception+0x22/0x330 ? exc_page_fault+0x6f/0x170 ? asm_exc_page_fault+0x22/0x30 ? bpf_tracing_prog_attach+0x279/0x560 ? btf_obj_id+0x5/0x10 bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30 do_syscall_64+0x41/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Return -EINVAL in this situation. Signed-off-by: Jiri Olsa Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com> --- kernel/bpf/syscall.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c index 9c56b5970d7e..82bb1be4dca2 100644 --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -3181,6 +3181,10 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog, * * - if prog->aux->dst_trampoline and tgt_prog is NULL, the program * was detached and is going for re-attachment. + * + * - if prog->aux->dst_trampoline is NULL and tgt_prog and prog->aux->attach_btf + * are NULL, then program was already attached and user did not provide + * tgt_prog_fd so we have no way to find out or create trampoline */ if (!prog->aux->dst_trampoline && !tgt_prog) { /* @@ -3194,6 +3198,11 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog, err = -EINVAL; goto out_unlock; } + /* We can allow re-attach only if we have valid attach_btf. */ + if (!prog->aux->attach_btf) { + err = -EINVAL; + goto out_unlock; + } btf_id = prog->aux->attach_btf_id; key = bpf_trampoline_compute_key(NULL, prog->aux->attach_btf, btf_id); } From patchwork Sat Dec 2 19:15:50 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dmitry Dolgov <9erthalion6@gmail.com> X-Patchwork-Id: 13477037 X-Patchwork-Delegate: bpf@iogearbox.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="gXPzwFj+" Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9CC23125 for ; Sat, 2 Dec 2023 11:19:51 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-54c4f95e27fso2109266a12.1 for ; Sat, 02 Dec 2023 11:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701544790; x=1702149590; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=R9rsC57otcPvRDJAp4KfgS6OnjP1RG0QZjfI6cDUsJc=; b=gXPzwFj+zuhaRIrd7jTYBiYPsQI0TUwZ2/klCMKqCA/qVO7IVvo2nUhjiyU0g+cZ3R ZdM8sl7jF5l9zdfDmimDbfjo3AcrLtErEn/vg8c/FGNS3QcyruOK5KeAJ65lYSWaTDdv v60m/UCUb1v+GxlaOxb6Hm6ZF9ajxp4yqQxAZFL+GGDZTwoyg3TkZb+8Cnhejt/EcKXr cMhS2zA7nC0zv4IkH9jyKO62jzgYX3X6G9qbD9kbnDvhiEPQKcP1yEy5sdQrKukzm7YK 1ozBbkWtanPn1lUC8wno1Rsx0EznjPtkQ8H9YPDI/4LblYbHTD/W20wTimVILEYmspxL wRnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701544790; x=1702149590; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=R9rsC57otcPvRDJAp4KfgS6OnjP1RG0QZjfI6cDUsJc=; b=MMlBXM8nkchm16P5/6N97IbCP/3YZHLHWlrQWI36n1KJIpgqA41OmLACRboIJvWYtN 3ObDiP+9rMZarymVhaD2zs1ZiGdJ4XbKCoP+VEeT53MDRAS75vyvZSV7CLhgptAoxlDV oMKklKQ5PcaQ0tskfcZFlfpUyuukM8WbXAYHrZWV6G6MeI1b8AHPZhAHYu7nJb/a4fR2 Vd0YeNroi4waNfEjEJ2P1BaJw1gIkZJf/MHNHqs7bbwnmRw+r0Qy/b4bEkmGRKeVwBCM W8SeOD4R8oMlGwIsTCSCXDFpSXgSI5nNAS8V3HuX/P/vgQupy70ae2K+q2PjgBl41cF1 fCBw== X-Gm-Message-State: AOJu0YyPPJIhzbHZkjAvEGNLym2FctdwiMX9RqTZfW7tVuYibyrfUo69 O3mMOs0/avJPBk4X0ZBvGlhh9GK42dzduw== X-Google-Smtp-Source: AGHT+IFkedhEEPWqR7c4obhyGMwjvI/L7TXvawkHY4LOwlHuBKOdELD32tJYmSv2eQ3ZCoCjD9NMjQ== X-Received: by 2002:a17:907:86a1:b0:a19:c22:f66e with SMTP id qa33-20020a17090786a100b00a190c22f66emr4049233ejc.55.1701544789899; Sat, 02 Dec 2023 11:19:49 -0800 (PST) Received: from localhost.localdomain ([2a00:20:6008:6fb9:fa16:54ff:fe6e:2940]) by smtp.gmail.com with ESMTPSA id i23-20020a170906115700b00a18ed83ce42sm3127814eja.15.2023.12.02.11.19.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Dec 2023 11:19:49 -0800 (PST) From: Dmitrii Dolgov <9erthalion6@gmail.com> To: bpf@vger.kernel.org Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev, dan.carpenter@linaro.org, olsajiri@gmail.com, asavkov@redhat.com, Dmitrii Dolgov <9erthalion6@gmail.com> Subject: [PATCH bpf-next v6 4/4] selftests/bpf: Test re-attachment fix for bpf_tracing_prog_attach Date: Sat, 2 Dec 2023 20:15:50 +0100 Message-ID: <20231202191556.30997-5-9erthalion6@gmail.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20231202191556.30997-1-9erthalion6@gmail.com> References: <20231202191556.30997-1-9erthalion6@gmail.com> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: bpf@iogearbox.net Add a test case to verify the fix for "prog->aux->dst_trampoline and tgt_prog is NULL" branch in bpf_tracing_prog_attach. The sequence of events: 1. load rawtp program 2. load fentry program with rawtp as target_fd 3. create tracing link for fentry program with target_fd = 0 4. repeat 3 Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com> --- .../bpf/prog_tests/recursive_attach.c | 48 +++++++++++++++++++ .../bpf/progs/fentry_recursive_target.c | 11 +++++ 2 files changed, 59 insertions(+) diff --git a/tools/testing/selftests/bpf/prog_tests/recursive_attach.c b/tools/testing/selftests/bpf/prog_tests/recursive_attach.c index 7248d0661ee9..6296bcf95481 100644 --- a/tools/testing/selftests/bpf/prog_tests/recursive_attach.c +++ b/tools/testing/selftests/bpf/prog_tests/recursive_attach.c @@ -67,3 +67,51 @@ void test_recursive_fentry_attach(void) fentry_recursive__destroy(tracing_chain[i]); } } + +/* + * Test that a tracing prog reattachment (when we land in + * "prog->aux->dst_trampoline and tgt_prog is NULL" branch in + * bpf_tracing_prog_attach) does not lead to a crash due to missing attach_btf + */ +void test_fentry_attach_btf_presence(void) +{ + struct fentry_recursive_target *target_skel = NULL; + struct fentry_recursive *tracing_skel = NULL; + struct bpf_program *prog; + int err, link_fd, tgt_prog_fd; + + target_skel = fentry_recursive_target__open_and_load(); + if (!ASSERT_OK_PTR(target_skel, "fentry_recursive_target__open_and_load")) + goto close_prog; + + tracing_skel = fentry_recursive__open(); + if (!ASSERT_OK_PTR(tracing_skel, "fentry_recursive__open")) + goto close_prog; + + prog = tracing_skel->progs.recursive_attach; + tgt_prog_fd = bpf_program__fd(target_skel->progs.fentry_target); + err = bpf_program__set_attach_target(prog, tgt_prog_fd, "fentry_target"); + if (!ASSERT_OK(err, "bpf_program__set_attach_target")) + goto close_prog; + + err = fentry_recursive__load(tracing_skel); + if (!ASSERT_OK(err, "fentry_recursive__load")) + goto close_prog; + + LIBBPF_OPTS(bpf_link_create_opts, link_opts); + + link_fd = bpf_link_create(bpf_program__fd(tracing_skel->progs.recursive_attach), + 0, BPF_TRACE_FENTRY, &link_opts); + if (!ASSERT_GE(link_fd, 0, "link_fd")) + goto close_prog; + + fentry_recursive__detach(tracing_skel); + + err = fentry_recursive__attach(tracing_skel); + if (!ASSERT_ERR(err, "fentry_recursive__attach")) + goto close_prog; + +close_prog: + fentry_recursive_target__destroy(target_skel); + fentry_recursive__destroy(tracing_skel); +} diff --git a/tools/testing/selftests/bpf/progs/fentry_recursive_target.c b/tools/testing/selftests/bpf/progs/fentry_recursive_target.c index b6fb8ebd598d..f812d2de0c3c 100644 --- a/tools/testing/selftests/bpf/progs/fentry_recursive_target.c +++ b/tools/testing/selftests/bpf/progs/fentry_recursive_target.c @@ -18,3 +18,14 @@ int BPF_PROG(test1, int a) test1_result = a == 1; return 0; } + +/* + * Dummy bpf prog for testing attach_btf presence when attaching an fentry + * program. + */ +SEC("raw_tp/sys_enter") +int BPF_PROG(fentry_target, struct pt_regs *regs, long id) +{ + test1_result = id == 1; + return 0; +}