From: Martin KaFai Lau <martin.lau@linux.dev>
To: Yonghong Song <yhs@meta.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
kernel-team@fb.com, Martin KaFai Lau <martin.lau@kernel.org>,
bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next] bpf: Handle MEM_RCU type properly
Date: Thu, 1 Dec 2022 14:05:21 -0800 [thread overview]
Message-ID: <71f4d953-fbfd-902f-bc8d-3894b7562eeb@linux.dev> (raw)
In-Reply-To: <1a534022-5629-8f98-c8ad-f1c335652af5@meta.com>
On 12/1/22 9:47 AM, Yonghong Song wrote:
>
>
> On 11/30/22 11:05 PM, Martin KaFai Lau wrote:
>> On 11/28/22 6:37 PM, Yonghong Song wrote:
>>> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
>>> index c05aa6e1f6f5..6f192dd9025e 100644
>>> --- a/include/linux/bpf_verifier.h
>>> +++ b/include/linux/bpf_verifier.h
>>> @@ -683,7 +683,7 @@ static inline bool bpf_prog_check_recur(const struct
>>> bpf_prog *prog)
>>> }
>>> }
>>> -#define BPF_REG_TRUSTED_MODIFIERS (MEM_ALLOC | MEM_RCU | PTR_TRUSTED)
>>> +#define BPF_REG_TRUSTED_MODIFIERS (MEM_ALLOC | PTR_TRUSTED)
>>
>> [ ... ]
>>
>>> +static bool is_rcu_reg(const struct bpf_reg_state *reg)
>>> +{
>>> + return reg->type & MEM_RCU;
>>> +}
>>> +
>>> static int check_pkt_ptr_alignment(struct bpf_verifier_env *env,
>>> const struct bpf_reg_state *reg,
>>> int off, int size, bool strict)
>>> @@ -4775,12 +4780,10 @@ static int check_ptr_to_btf_access(struct
>>> bpf_verifier_env *env,
>>> /* Mark value register as MEM_RCU only if it is protected by
>>> * bpf_rcu_read_lock() and the ptr reg is trusted. MEM_RCU
>>> * itself can already indicate trustedness inside the rcu
>>> - * read lock region. Also mark it as PTR_TRUSTED.
>>> + * read lock region.
>>> */
>>> if (!env->cur_state->active_rcu_lock || !is_trusted_reg(reg))
>>> flag &= ~MEM_RCU;
>>
>> How about dereferencing a PTR_TO_BTF_ID | MEM_RCU, like:
>>
>> /* parent: PTR_TO_BTF_ID | MEM_RCU */
>> parent = current->real_parent;
>> /* gparent: PTR_TO_BTF_ID */
>> gparent = parent->real_parent;
>>
>> Should "gparent" have MEM_RCU also?
>
> Currently, no. We have logic in the code like
>
> if (flag & MEM_RCU) {
> /* Mark value register as MEM_RCU only if it is protected by
> * bpf_rcu_read_lock() and the ptr reg is trusted. MEM_RCU
> * itself can already indicate trustedness inside the rcu
> * read lock region.
> */
> if (!env->cur_state->active_rcu_lock || !is_trusted_reg(reg))
> flag &= ~MEM_RCU;
> }
>
> Since 'parent' is not trusted, so it will not be marked as MEM_RCU.
> It can be marked as MEM_RCU if we do (based on the current patch)
or adding a is_rcu_trusted_reg() to consider both is_trusted_reg and MEM_RCU
before cleaning ~MEM_RCU here. It seems the check_kfunc_args() below will need
a similar is_rcu_trusted_reg() test also.
>
> parent = current->real_parent;
> parent2 = bpf_task_acquire_rcu(parent);
> if (!parent2) goto out;
> gparent = parent2->real_parent;
>
> Now gparent will be marked as MEM_RCU.
>
>>
>> Also, should PTR_MAYBE_NULL be added to "parent"?
>
> I think we might need to do this. Although from kernel code,
> task->real_parent, current->cgroups seem not NULL. But for sure
> there are cases where the rcu ptr could be NULL. This might
> be conservative for some cases, and if it is absolutely
> performance critical, we later could tag related __rcu member
> with btf_decl_tag to indicate its non-null status.
>
>>
>>> - else
>>> - flag |= PTR_TRUSTED;
>>> } else if (reg->type & MEM_RCU) {
>>> /* ptr (reg) is marked as MEM_RCU, but the struct field is not tagged
>>> * with __rcu. Mark the flag as PTR_UNTRUSTED conservatively.
>>> @@ -5945,7 +5948,7 @@ static const struct bpf_reg_types btf_ptr_types = {
>>> .types = {
>>> PTR_TO_BTF_ID,
>>> PTR_TO_BTF_ID | PTR_TRUSTED,
>>> - PTR_TO_BTF_ID | MEM_RCU | PTR_TRUSTED,
>>> + PTR_TO_BTF_ID | MEM_RCU,
>>> },
>>> };
>>> static const struct bpf_reg_types percpu_btf_ptr_types = {
>>> @@ -6124,7 +6127,7 @@ int check_func_arg_reg_off(struct bpf_verifier_env *env,
>>> case PTR_TO_BTF_ID:
>>> case PTR_TO_BTF_ID | MEM_ALLOC:
>>> case PTR_TO_BTF_ID | PTR_TRUSTED:
>>> - case PTR_TO_BTF_ID | MEM_RCU | PTR_TRUSTED:
>>> + case PTR_TO_BTF_ID | MEM_RCU:
>>> case PTR_TO_BTF_ID | MEM_ALLOC | PTR_TRUSTED:
>>> /* When referenced PTR_TO_BTF_ID is passed to release function,
>>> * it's fixed offset must be 0. In the other cases, fixed offset
>>> @@ -8022,6 +8025,11 @@ static bool is_kfunc_destructive(struct
>>> bpf_kfunc_call_arg_meta *meta)
>>> return meta->kfunc_flags & KF_DESTRUCTIVE;
>>> }
>>> +static bool is_kfunc_rcu(struct bpf_kfunc_call_arg_meta *meta)
>>> +{
>>> + return meta->kfunc_flags & KF_RCU;
>>> +}
>>> +
>>> static bool is_kfunc_arg_kptr_get(struct bpf_kfunc_call_arg_meta *meta, int
>>> arg)
>>> {
>>> return arg == 0 && (meta->kfunc_flags & KF_KPTR_GET);
>>> @@ -8706,13 +8714,19 @@ static int check_kfunc_args(struct bpf_verifier_env
>>> *env, struct bpf_kfunc_call_
>>> switch (kf_arg_type) {
>>> case KF_ARG_PTR_TO_ALLOC_BTF_ID:
>>> case KF_ARG_PTR_TO_BTF_ID:
>>> - if (!is_kfunc_trusted_args(meta))
>>> + if (!is_kfunc_trusted_args(meta) && !is_kfunc_rcu(meta))
>>> break;
>>> - if (!is_trusted_reg(reg)) {
>>> - verbose(env, "R%d must be referenced or trusted\n", regno);
>>> + if (!is_trusted_reg(reg) && !is_rcu_reg(reg)) {
>>> + verbose(env, "R%d must be referenced, trusted or rcu\n",
>>> regno);
>>> return -EINVAL;
>>> }
>>> +
>>> + if (is_kfunc_rcu(meta) != is_rcu_reg(reg)) {
>>
>> I think is_trusted_reg(reg) should also be acceptable to bpf_task_acquire_rcu().
>
> Yes, good point. trusted is a super set of rcu.
>
>>
>> nit. bpf_task_acquire_not_zero() may be a better kfunc name.
>
> Will use this one.
next prev parent reply other threads:[~2022-12-01 22:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-29 2:37 [PATCH bpf-next] bpf: Handle MEM_RCU type properly Yonghong Song
2022-11-30 0:11 ` Yonghong Song
2022-12-01 7:05 ` Martin KaFai Lau
2022-12-01 17:47 ` Yonghong Song
2022-12-01 22:05 ` Martin KaFai Lau [this message]
2022-12-02 0:08 ` 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=71f4d953-fbfd-902f-bc8d-3894b7562eeb@linux.dev \
--to=martin.lau@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
--cc=martin.lau@kernel.org \
--cc=yhs@meta.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.