BPF List
 help / color / mirror / Atom feed
From: Yonghong Song <yhs@fb.com>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>
Subject: Re: [PATCH bpf-next v1 1/2] bpf: Ensure type tags precede modifiers in BTF
Date: Mon, 18 Apr 2022 15:22:14 -0700	[thread overview]
Message-ID: <19b5e6fa-b041-a824-362e-a1cc7615d253@fb.com> (raw)
In-Reply-To: <20220418203108.zsyox6jr4k5al5yo@apollo.legion>



On 4/18/22 1:31 PM, Kumar Kartikeya Dwivedi wrote:
> On Tue, Apr 19, 2022 at 01:23:32AM IST, Yonghong Song wrote:
>>
>>
>> On 4/5/22 5:41 PM, Kumar Kartikeya Dwivedi wrote:
>>> It is guaranteed that for modifiers, clang always places type tags
>>> before other modifiers, and then the base type. We would like to rely on
>>> this guarantee inside the kernel to make it simple to parse type tags
>>> from BTF.
>>>
>>> However, a user would be allowed to construct a BTF without such
>>> guarantees. Hence, add a pass to check that in modifier chains, type
>>> tags only occur at the head of the chain, and then don't occur later in
>>> the chain.
>>>
>>> If we see a type tag, we can have one or more type tags preceding other
>>> modifiers that then never have another type tag. If we see other
>>> modifiers, all modifiers following them should never be a type tag.
>>>
>>> Instead of having to walk chains we verified previously, we can remember
>>> the last good modifier type ID which headed a good chain. At that point,
>>> we must have verified all other chains headed by type IDs less than it.
>>> This makes the verification process less costly, and it becomes a simple
>>> O(n) pass.
>>>
>>> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
>>> ---
>>>    kernel/bpf/btf.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++++
>>>    1 file changed, 51 insertions(+)
>>>
>>> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
>>> index 0918a39279f6..4a73f5b8127e 100644
>>> --- a/kernel/bpf/btf.c
>>> +++ b/kernel/bpf/btf.c
>>> @@ -4541,6 +4541,45 @@ static int btf_parse_hdr(struct btf_verifier_env *env)
>>>    	return 0;
>>>    }
>>> +static int btf_check_type_tags(struct btf_verifier_env *env,
>>> +			       struct btf *btf, int start_id)
>>> +{
>>> +	int i, n, good_id = start_id - 1;
>>> +	bool in_tags;
>>> +
>>> +	n = btf_nr_types(btf);
>>> +	for (i = start_id; i < n; i++) {
>>> +		const struct btf_type *t;
>>> +
>>> +		t = btf_type_by_id(btf, i);
>>> +		if (!t)
>>> +			return -EINVAL;
>>> +		if (!btf_type_is_modifier(t))
>>> +			continue;
>>> +
>>> +		cond_resched();
>>> +
>>> +		in_tags = btf_type_is_type_tag(t);
>>> +		while (btf_type_is_modifier(t)) {
>>> +			if (btf_type_is_type_tag(t)) {
>>> +				if (!in_tags) {
>>> +					btf_verifier_log(env, "Type tags don't precede modifiers");
>>> +					return -EINVAL;
>>> +				}
>>> +			} else if (in_tags) {
>>> +				in_tags = false;
>>> +			}
>>> +			if (t->type <= good_id)
>>> +				break;
>>
>> General approach looks good. Currently verifier does assume type_tag
>> immediately following ptr type and before all other modifiers we do
>> need to ensure
>>
>> I think we may have an issue here though. Suppose we have the
>> following types
>>     1 ptr -> 2
>>     2 tag -> 3
>>     3 const -> 4
>>     4 int
>>     5 ptr -> 6
>>     6 const -> 2
>>
>> In this particular case, when processing modifier 6, we
>> have in_tags is false, but t->type (2) <= good_id (5).
>> But this is illegal as we have ptr-> const -> tag -> const -> int.
>>
> 
> Thanks a lot for catching the bug.
> 
> So when we have set a non-zero good_id, we know two things:
> If good_id is a type tag, it will be followed by one or more type tag modifiers
> and then only non type tag modifiers, else it will only be a series of non type
> tag modifiers.
> 
> When comparing next type ID (t->type) with good_id, we need to see if it is a
> type_tag and compare against in_tags to ensure it can be part of current chain.
> So this t->type check needs to be changed to be against current type ID, and
> should happen in next loop iteration after in_tags has been checked against 't'.
> 
> The following change should fix this:
> 
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 4a73f5b8127e..c015ccd1c741 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -4550,6 +4550,7 @@ static int btf_check_type_tags(struct btf_verifier_env *env,
>          n = btf_nr_types(btf);
>          for (i = start_id; i < n; i++) {
>                  const struct btf_type *t;
> +               u32 cur_id = i;
> 
>                  t = btf_type_by_id(btf, i);
>                  if (!t)
> @@ -4569,8 +4570,10 @@ static int btf_check_type_tags(struct btf_verifier_env *env,
>                          } else if (in_tags) {
>                                  in_tags = false;
>                          }
> -                       if (t->type <= good_id)
> +                       if (cur_id <= good_id)
>                                  break;
> +                       /* Move to next type */
> +                       cur_id = t->type;
>                          t = btf_type_by_id(btf, t->type);
>                          if (!t)
>                                  return -EINVAL;
> 
> --
> 
> If it looks good, I can respin with your example added as another test in
> selftests.

I checked and it looks good to me. Right, it would be great if an 
selftest is added for this pattern.

[...]

  reply	other threads:[~2022-04-18 22:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-06  0:41 [PATCH bpf-next v1 0/2] Ensure type tags are always ordered first in BTF Kumar Kartikeya Dwivedi
2022-04-06  0:41 ` [PATCH bpf-next v1 1/2] bpf: Ensure type tags precede modifiers " Kumar Kartikeya Dwivedi
2022-04-18 19:53   ` Yonghong Song
2022-04-18 20:31     ` Kumar Kartikeya Dwivedi
2022-04-18 22:22       ` Yonghong Song [this message]
2022-04-06  0:41 ` [PATCH bpf-next v1 2/2] selftests/bpf: Add tests for type tag order validation Kumar Kartikeya Dwivedi
2022-04-13  3:23 ` [PATCH bpf-next v1 0/2] Ensure type tags are always ordered first in BTF Andrii Nakryiko

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=19b5e6fa-b041-a824-362e-a1cc7615d253@fb.com \
    --to=yhs@fb.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=memxor@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox