From: Kumar Kartikeya Dwivedi <memxor@gmail.com>
To: bpf@vger.kernel.org
Cc: "Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Martin KaFai Lau" <kafai@fb.com>,
"Song Liu" <songliubraving@fb.com>, "Yonghong Song" <yhs@fb.com>,
"John Fastabend" <john.fastabend@gmail.com>,
"Maxim Mikityanskiy" <maximmi@nvidia.com>,
"Florian Westphal" <fw@strlen.de>,
"Jesper Dangaard Brouer" <brouer@redhat.com>,
"Toke Høiland-Jørgensen" <toke@redhat.com>,
netdev@vger.kernel.org, netfilter-devel@vger.kernel.org
Subject: [PATCH bpf-next v2 6/9] bpf: Track provenance for pointers formed from referenced PTR_TO_BTF_ID
Date: Thu, 9 Dec 2021 22:39:26 +0530 [thread overview]
Message-ID: <20211209170929.3485242-7-memxor@gmail.com> (raw)
In-Reply-To: <20211209170929.3485242-1-memxor@gmail.com>
In the previous commit, we implemented support in the verifier for
working with referenced PTR_TO_BTF_ID registers. These are invalidated
when their corresponding release function is called.
However, PTR_TO_BTF_ID is a bit special, in that distinct PTR_TO_BTF_ID
can be formed by walking pointers in the struct represented by the BTF
ID. mark_btf_ld_reg will copy the relevant register state to the
destination register.
However, we cannot simply copy ref_obj_id (such that
release_reg_references will match and invalidate all pointers formed by
pointer walking), as we obtain the same BTF ID in the destination
register, leading to confusion during release. An example is show below:
For a type like so:
struct foo { struct foo *next; };
r1 = acquire(...); // BTF ID of struct foo
if (r1) {
r2 = r1->next; // BTF ID of struct foo, and we copied ref_obj_id in
// mark_btf_ld_reg.
release(r2);
}
With this logic, the above snippet succeeds. Hence we need to
distinguish the canonical reference and pointers formed from it.
We introduce a 'parent_ref_obj_id' member in bpf_reg_state, for a
referenced register, only one of ref_obj_id or parent_ref_obj_id may be
set, i.e. either a register holds a canonical reference, or it is
related to a canonical reference for invalidation purposes (contains an
edge pointing to it by way of having the same ref_obj_id in
parent_ref_obj_id, in the graph of objects).
When releasing reference, we ensure that both are not set at once, and
then release if either of them match the requested ref_obj_id to be
released. This ensures that the example given above will not succeed.
A test to this end has been added in later patches.
Typically, kernel objects have a nested object lifetime (where the
parent object 'owns' the objects it holds references to). However, this
is not always true. For now, we don't need support to hold on to
references to objects obtained from a refcounted PTR_TO_BTF_ID after its
release, but this can be relaxed on a case by case basis (i.e. based on
the BTF ID and program type/attach type) in the future.
The safest assumption for the verifier to make in absence of any other
hints, is that all such pointers formed from refcounted PTR_TO_BTF_ID
shall be invalidated.
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
---
include/linux/bpf_verifier.h | 10 +++++++
kernel/bpf/verifier.c | 54 ++++++++++++++++++++++++++++--------
2 files changed, 52 insertions(+), 12 deletions(-)
diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
index b80fe5bf2a02..a6ef11db6823 100644
--- a/include/linux/bpf_verifier.h
+++ b/include/linux/bpf_verifier.h
@@ -128,6 +128,16 @@ struct bpf_reg_state {
* allowed and has the same effect as bpf_sk_release(sk).
*/
u32 ref_obj_id;
+ /* This is set for pointers which are derived from referenced
+ * pointer (e.g. PTR_TO_BTF_ID pointer walking), so that the
+ * pointers obtained by walking referenced PTR_TO_BTF_ID
+ * are appropriately invalidated when the lifetime of their
+ * parent object ends.
+ *
+ * Only one of ref_obj_id and parent_ref_obj_id can be set,
+ * never both at once.
+ */
+ u32 parent_ref_obj_id;
/* For scalar types (SCALAR_VALUE), this represents our knowledge of
* the actual value.
* For pointer types, this represents the variable part of the offset
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index b8685fb7ff15..16e30d7f631b 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -654,7 +654,8 @@ static void print_verifier_state(struct bpf_verifier_env *env,
verbose(env, "%s", kernel_type_name(reg->btf, reg->btf_id));
verbose(env, "(id=%d", reg->id);
if (reg_type_may_be_refcounted_or_null(t))
- verbose(env, ",ref_obj_id=%d", reg->ref_obj_id);
+ verbose(env, ",%sref_obj_id=%d", reg->ref_obj_id ? "" : "parent_",
+ reg->ref_obj_id ?: reg->parent_ref_obj_id);
if (t != SCALAR_VALUE)
verbose(env, ",off=%d", reg->off);
if (type_is_pkt_pointer(t))
@@ -1500,7 +1501,8 @@ static void mark_reg_not_init(struct bpf_verifier_env *env,
static void mark_btf_ld_reg(struct bpf_verifier_env *env,
struct bpf_reg_state *regs, u32 regno,
enum bpf_reg_type reg_type,
- struct btf *btf, u32 btf_id)
+ struct btf *btf, u32 btf_id,
+ u32 parent_ref_obj_id)
{
if (reg_type == SCALAR_VALUE) {
mark_reg_unknown(env, regs, regno);
@@ -1509,6 +1511,7 @@ static void mark_btf_ld_reg(struct bpf_verifier_env *env,
mark_reg_known_zero(env, regs, regno);
regs[regno].type = PTR_TO_BTF_ID;
regs[regno].btf = btf;
+ regs[regno].parent_ref_obj_id = parent_ref_obj_id;
regs[regno].btf_id = btf_id;
}
@@ -4136,8 +4139,14 @@ static int check_ptr_to_btf_access(struct bpf_verifier_env *env,
if (ret < 0)
return ret;
- if (atype == BPF_READ && value_regno >= 0)
- mark_btf_ld_reg(env, regs, value_regno, ret, reg->btf, btf_id);
+ if (atype == BPF_READ && value_regno >= 0) {
+ if (WARN_ON_ONCE(reg->ref_obj_id && reg->parent_ref_obj_id)) {
+ verbose(env, "verifier internal error: both ref and parent ref set\n");
+ return -EACCES;
+ }
+ mark_btf_ld_reg(env, regs, value_regno, ret, reg->btf, btf_id,
+ reg->ref_obj_id ?: reg->parent_ref_obj_id);
+ }
return 0;
}
@@ -4191,8 +4200,14 @@ static int check_ptr_to_map_access(struct bpf_verifier_env *env,
if (ret < 0)
return ret;
- if (value_regno >= 0)
- mark_btf_ld_reg(env, regs, value_regno, ret, btf_vmlinux, btf_id);
+ if (value_regno >= 0) {
+ if (WARN_ON_ONCE(reg->ref_obj_id && reg->parent_ref_obj_id)) {
+ verbose(env, "verifier internal error: both ref and parent ref set\n");
+ return -EACCES;
+ }
+ mark_btf_ld_reg(env, regs, value_regno, ret, btf_vmlinux, btf_id,
+ reg->ref_obj_id ?: reg->parent_ref_obj_id);
+ }
return 0;
}
@@ -5865,23 +5880,35 @@ static void mark_pkt_end(struct bpf_verifier_state *vstate, int regn, bool range
reg->range = AT_PKT_END;
}
-static void release_reg_references(struct bpf_verifier_env *env,
+static int release_reg_references(struct bpf_verifier_env *env,
struct bpf_func_state *state,
int ref_obj_id)
{
struct bpf_reg_state *regs = state->regs, *reg;
int i;
- for (i = 0; i < MAX_BPF_REG; i++)
- if (regs[i].ref_obj_id == ref_obj_id)
+ for (i = 0; i < MAX_BPF_REG; i++) {
+ if (WARN_ON_ONCE(regs[i].ref_obj_id && regs[i].parent_ref_obj_id)) {
+ verbose(env, "verifier internal error: both ref and parent ref set\n");
+ return -EACCES;
+ }
+ if (regs[i].ref_obj_id == ref_obj_id ||
+ regs[i].parent_ref_obj_id == ref_obj_id)
mark_reg_unknown(env, regs, i);
+ }
bpf_for_each_spilled_reg(i, state, reg) {
if (!reg)
continue;
- if (reg->ref_obj_id == ref_obj_id)
+ if (WARN_ON_ONCE(reg->ref_obj_id && reg->parent_ref_obj_id)) {
+ verbose(env, "verifier internal error: both ref and parent ref set\n");
+ return -EACCES;
+ }
+ if (reg->ref_obj_id == ref_obj_id ||
+ reg->parent_ref_obj_id == ref_obj_id)
__mark_reg_unknown(env, reg);
}
+ return 0;
}
/* The pointer with the specified id has released its reference to kernel
@@ -5898,8 +5925,11 @@ static int release_reference(struct bpf_verifier_env *env,
if (err)
return err;
- for (i = 0; i <= vstate->curframe; i++)
- release_reg_references(env, vstate->frame[i], ref_obj_id);
+ for (i = 0; i <= vstate->curframe; i++) {
+ err = release_reg_references(env, vstate->frame[i], ref_obj_id);
+ if (err)
+ return err;
+ }
return 0;
}
--
2.34.1
next prev parent reply other threads:[~2021-12-09 17:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-09 17:09 [PATCH bpf-next v2 0/9] Introduce unstable CT lookup helpers Kumar Kartikeya Dwivedi
2021-12-09 17:09 ` [PATCH bpf-next v2 1/9] bpf: Refactor bpf_check_mod_kfunc_call Kumar Kartikeya Dwivedi
2021-12-09 17:09 ` [PATCH bpf-next v2 2/9] bpf: Remove DEFINE_KFUNC_BTF_ID_SET Kumar Kartikeya Dwivedi
2021-12-09 17:09 ` [PATCH bpf-next v2 3/9] bpf: Extend kfunc with PTR_TO_CTX, PTR_TO_MEM argument support Kumar Kartikeya Dwivedi
2021-12-09 17:09 ` [PATCH bpf-next v2 4/9] bpf: Introduce mem, size argument pair support for kfunc Kumar Kartikeya Dwivedi
2021-12-09 17:09 ` [PATCH bpf-next v2 5/9] bpf: Add reference tracking support to kfunc Kumar Kartikeya Dwivedi
2021-12-09 17:09 ` Kumar Kartikeya Dwivedi [this message]
2021-12-09 17:09 ` [PATCH bpf-next v2 7/9] net/netfilter: Add unstable CT lookup helpers for XDP and TC-BPF Kumar Kartikeya Dwivedi
2021-12-09 17:09 ` [PATCH bpf-next v2 8/9] selftests/bpf: Extend kfunc selftests Kumar Kartikeya Dwivedi
2021-12-09 17:09 ` [PATCH bpf-next v2 9/9] selftests/bpf: Add test for unstable CT lookup API Kumar Kartikeya Dwivedi
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=20211209170929.3485242-7-memxor@gmail.com \
--to=memxor@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=fw@strlen.de \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=maximmi@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=songliubraving@fb.com \
--cc=toke@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.