bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Alexei Starovoitov <ast@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>,
	Daniel Borkmann <daniel@iogearbox.net>,
	x86@kernel.org, Networking <netdev@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>, Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH bpf-next 03/10] bpf: process in-kernel BTF
Date: Sat, 5 Oct 2019 23:36:16 -0700	[thread overview]
Message-ID: <CAEf4BzahO9XjK7rMYa+DdRRhm2z4MmjD9Y-n3DWGd-W-G3mYRQ@mail.gmail.com> (raw)
In-Reply-To: <20191005050314.1114330-4-ast@kernel.org>

On Fri, Oct 4, 2019 at 10:08 PM Alexei Starovoitov <ast@kernel.org> wrote:
>
> If in-kernel BTF exists parse it and prepare 'struct btf *btf_vmlinux'
> for further use by the verifier.
> In-kernel BTF is trusted just like kallsyms and other build artifacts
> embedded into vmlinux.
> Yet run this BTF image through BTF verifier to make sure
> that it is valid and it wasn't mangled during the build.
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> ---
>  include/linux/bpf_verifier.h |  4 ++-
>  include/linux/btf.h          |  1 +
>  kernel/bpf/btf.c             | 66 ++++++++++++++++++++++++++++++++++++
>  kernel/bpf/verifier.c        | 18 ++++++++++
>  4 files changed, 88 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> index 26a6d58ca78c..432ba8977a0a 100644
> --- a/include/linux/bpf_verifier.h
> +++ b/include/linux/bpf_verifier.h
> @@ -330,10 +330,12 @@ static inline bool bpf_verifier_log_full(const struct bpf_verifier_log *log)
>  #define BPF_LOG_STATS  4
>  #define BPF_LOG_LEVEL  (BPF_LOG_LEVEL1 | BPF_LOG_LEVEL2)
>  #define BPF_LOG_MASK   (BPF_LOG_LEVEL | BPF_LOG_STATS)
> +#define BPF_LOG_KERNEL (BPF_LOG_MASK + 1)

It's not clear what's the numbering scheme is for these flags. Are
they independent bits? Only one bit allowed at a time? Only some
subset of bits allowed?
E.g., if I specify BPF_LOG_KERNEL an BPF_LOG_STATS, will it work?

If it's bits, then specifying BPF_LOG_KERNEL as (BPF_LOG_MASK + 1)
looks weird, setting it to 8 would be more obvious and
straightforward.

>
>  static inline bool bpf_verifier_log_needed(const struct bpf_verifier_log *log)
>  {
> -       return log->level && log->ubuf && !bpf_verifier_log_full(log);
> +       return (log->level && log->ubuf && !bpf_verifier_log_full(log)) ||
> +               log->level == BPF_LOG_KERNEL;
>  }
>
>  #define BPF_MAX_SUBPROGS 256
> diff --git a/include/linux/btf.h b/include/linux/btf.h
> index 64cdf2a23d42..55d43bc856be 100644
> --- a/include/linux/btf.h
> +++ b/include/linux/btf.h
> @@ -56,6 +56,7 @@ bool btf_type_is_void(const struct btf_type *t);
>  #ifdef CONFIG_BPF_SYSCALL
>  const struct btf_type *btf_type_by_id(const struct btf *btf, u32 type_id);
>  const char *btf_name_by_offset(const struct btf *btf, u32 offset);
> +struct btf *btf_parse_vmlinux(void);
>  #else
>  static inline const struct btf_type *btf_type_by_id(const struct btf *btf,
>                                                     u32 type_id)
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 29c7c06c6bd6..848f9d4b9d7e 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -698,6 +698,9 @@ __printf(4, 5) static void __btf_verifier_log_type(struct btf_verifier_env *env,
>         if (!bpf_verifier_log_needed(log))
>                 return;
>
> +       if (log->level == BPF_LOG_KERNEL && !fmt)
> +               return;

This "!fmt" condition is subtle and took me a bit of time to
understand. Is the intent to print only verification errors for
BPF_LOG_KERNEL mode? Maybe small comment would help?

> +
>         __btf_verifier_log(log, "[%u] %s %s%s",
>                            env->log_type_id,
>                            btf_kind_str[kind],
> @@ -735,6 +738,8 @@ static void btf_verifier_log_member(struct btf_verifier_env *env,
>         if (!bpf_verifier_log_needed(log))
>                 return;
>
> +       if (log->level == BPF_LOG_KERNEL && !fmt)
> +               return;
>         /* The CHECK_META phase already did a btf dump.
>          *
>          * If member is logged again, it must hit an error in
> @@ -777,6 +782,8 @@ static void btf_verifier_log_vsi(struct btf_verifier_env *env,
>
>         if (!bpf_verifier_log_needed(log))
>                 return;
> +       if (log->level == BPF_LOG_KERNEL && !fmt)
> +               return;
>         if (env->phase != CHECK_META)
>                 btf_verifier_log_type(env, datasec_type, NULL);
>
> @@ -802,6 +809,8 @@ static void btf_verifier_log_hdr(struct btf_verifier_env *env,
>         if (!bpf_verifier_log_needed(log))
>                 return;
>
> +       if (log->level == BPF_LOG_KERNEL)
> +               return;
>         hdr = &btf->hdr;
>         __btf_verifier_log(log, "magic: 0x%x\n", hdr->magic);
>         __btf_verifier_log(log, "version: %u\n", hdr->version);
> @@ -2406,6 +2415,8 @@ static s32 btf_enum_check_meta(struct btf_verifier_env *env,
>                 }
>
>

nit: extra empty line here, might as well get rid of it in this change?

> +               if (env->log.level == BPF_LOG_KERNEL)
> +                       continue;
>                 btf_verifier_log(env, "\t%s val=%d\n",
>                                  __btf_name_by_offset(btf, enums[i].name_off),
>                                  enums[i].val);
> @@ -3367,6 +3378,61 @@ static struct btf *btf_parse(void __user *btf_data, u32 btf_data_size,
>         return ERR_PTR(err);
>  }
>
> +extern char __weak _binary__btf_vmlinux_bin_start[];
> +extern char __weak _binary__btf_vmlinux_bin_end[];
> +
> +struct btf *btf_parse_vmlinux(void)

It's a bit unfortunate to duplicate a bunch of logic of btf_parse()
here. I assume you considered extending btf_parse() with extra flag
but decided it's better to have separate vmlinux-specific version?

> +{
> +       struct btf_verifier_env *env = NULL;
> +       struct bpf_verifier_log *log;
> +       struct btf *btf = NULL;
> +       int err;
> +

[...]

>         if (!copy_to_user(log->ubuf + log->len_used, log->kbuf, n + 1))
>                 log->len_used += n;
>         else
> @@ -9241,6 +9247,12 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr,
>         env->ops = bpf_verifier_ops[env->prog->type];
>         is_priv = capable(CAP_SYS_ADMIN);
>
> +       if (is_priv && !btf_vmlinux) {

I'm missing were you are checking that vmlinux BTF (raw data) is
present at all? Should this have additional `&&
_binary__btf_vmlinux_bin_start` check?

> +               mutex_lock(&bpf_verifier_lock);
> +               btf_vmlinux = btf_parse_vmlinux();

This is racy, you might end up parsing vmlinux BTF twice. Check
`!btf_vmlinux` again under lock?

> +               mutex_unlock(&bpf_verifier_lock);
> +       }
> +
>         /* grab the mutex to protect few globals used by verifier */
>         if (!is_priv)
>                 mutex_lock(&bpf_verifier_lock);
> @@ -9260,6 +9272,12 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr,
>                         goto err_unlock;
>         }
>
> +       if (IS_ERR(btf_vmlinux)) {

There is an interesting interplay between non-priviledged BPF and
corrupted vmlinux. If vmlinux BTF is malformed, but system only ever
does unprivileged BPF, then we'll never parse vmlinux BTF and won't
know it's malformed. But once some privileged BPF does parse and
detect problem, all subsequent unprivileged BPFs will fail due to bad
BTF, even though they shouldn't use/rely on it. Should something be
done about this inconsistency?

> +               verbose(env, "in-kernel BTF is malformed\n");
> +               ret = PTR_ERR(btf_vmlinux);
> +               goto err_unlock;
> +       }
> +
>         env->strict_alignment = !!(attr->prog_flags & BPF_F_STRICT_ALIGNMENT);
>         if (!IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS))
>                 env->strict_alignment = true;
> --
> 2.20.0
>

  reply	other threads:[~2019-10-06  6:36 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-05  5:03 [PATCH bpf-next 00/10] bpf: revolutionize bpf tracing Alexei Starovoitov
2019-10-05  5:03 ` [PATCH bpf-next 01/10] bpf: add typecast to raw_tracepoints to help BTF generation Alexei Starovoitov
2019-10-05 18:40   ` Andrii Nakryiko
2019-10-06  3:58   ` John Fastabend
2019-10-05  5:03 ` [PATCH bpf-next 02/10] bpf: add typecast to bpf helpers " Alexei Starovoitov
2019-10-05 18:41   ` Andrii Nakryiko
2019-10-06  4:00   ` John Fastabend
2019-10-05  5:03 ` [PATCH bpf-next 03/10] bpf: process in-kernel BTF Alexei Starovoitov
2019-10-06  6:36   ` Andrii Nakryiko [this message]
2019-10-06 23:49     ` Alexei Starovoitov
2019-10-07  0:20       ` Andrii Nakryiko
2019-10-09 20:51   ` Martin Lau
2019-10-10  3:43     ` Alexei Starovoitov
2019-10-05  5:03 ` [PATCH bpf-next 04/10] libbpf: auto-detect btf_id of raw_tracepoint Alexei Starovoitov
2019-10-07 23:41   ` Andrii Nakryiko
2019-10-09  2:26     ` Alexei Starovoitov
2019-10-05  5:03 ` [PATCH bpf-next 05/10] bpf: implement accurate raw_tp context access via BTF Alexei Starovoitov
2019-10-07 16:32   ` Alan Maguire
2019-10-09  3:59     ` Alexei Starovoitov
2019-10-08  0:35   ` Andrii Nakryiko
2019-10-09  3:30     ` Alexei Starovoitov
2019-10-09  4:01       ` Andrii Nakryiko
2019-10-09  5:10         ` Andrii Nakryiko
2019-10-10  3:54           ` Alexei Starovoitov
2019-10-05  5:03 ` [PATCH bpf-next 06/10] bpf: add support for BTF pointers to interpreter Alexei Starovoitov
2019-10-08  3:08   ` Andrii Nakryiko
2019-10-05  5:03 ` [PATCH bpf-next 07/10] bpf: add support for BTF pointers to x86 JIT Alexei Starovoitov
2019-10-05  6:03   ` Eric Dumazet
2019-10-09 17:38   ` Andrii Nakryiko
2019-10-09 17:46     ` Alexei Starovoitov
2019-10-05  5:03 ` [PATCH bpf-next 08/10] bpf: check types of arguments passed into helpers Alexei Starovoitov
2019-10-09 18:01   ` Andrii Nakryiko
2019-10-09 19:58     ` Alexei Starovoitov
2019-10-05  5:03 ` [PATCH bpf-next 09/10] bpf: disallow bpf_probe_read[_str] helpers Alexei Starovoitov
2019-10-09  5:29   ` Andrii Nakryiko
2019-10-09 19:38     ` Alexei Starovoitov
2019-10-05  5:03 ` [PATCH bpf-next 10/10] selftests/bpf: add kfree_skb raw_tp test Alexei Starovoitov
2019-10-09  5:36   ` Andrii Nakryiko
2019-10-09 17:37     ` Alexei Starovoitov

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=CAEf4BzahO9XjK7rMYa+DdRRhm2z4MmjD9Y-n3DWGd-W-G3mYRQ@mail.gmail.com \
    --to=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=kernel-team@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=x86@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).