[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAADnVQLDwjE8KFcqbzB5op5b=fC2941tnnWOtQ+X1DYi6Yw1xA@mail.gmail.com>
Date: Thu, 6 May 2021 18:36:38 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Jiri Olsa <jolsa@...nel.org>
Cc: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andriin@...com>,
Network Development <netdev@...r.kernel.org>,
bpf <bpf@...r.kernel.org>, Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...omium.org>
Subject: Re: [PATCHv2] bpf: Add deny list of btf ids check for tracing programs
On Thu, Apr 29, 2021 at 4:47 AM Jiri Olsa <jolsa@...nel.org> wrote:
>
> The recursion check in __bpf_prog_enter and __bpf_prog_exit
> leaves some (not inlined) functions unprotected:
>
> In __bpf_prog_enter:
> - migrate_disable is called before prog->active is checked
>
> In __bpf_prog_exit:
> - migrate_enable,rcu_read_unlock_strict are called after
> prog->active is decreased
>
> When attaching trampoline to them we get panic like:
>
> traps: PANIC: double fault, error_code: 0x0
> double fault: 0000 [#1] SMP PTI
> RIP: 0010:__bpf_prog_enter+0x4/0x50
> ...
> Call Trace:
> <IRQ>
> bpf_trampoline_6442466513_0+0x18/0x1000
> migrate_disable+0x5/0x50
> __bpf_prog_enter+0x9/0x50
> bpf_trampoline_6442466513_0+0x18/0x1000
> migrate_disable+0x5/0x50
> __bpf_prog_enter+0x9/0x50
> bpf_trampoline_6442466513_0+0x18/0x1000
> migrate_disable+0x5/0x50
> __bpf_prog_enter+0x9/0x50
> bpf_trampoline_6442466513_0+0x18/0x1000
> migrate_disable+0x5/0x50
> ...
>
> Fixing this by adding deny list of btf ids for tracing
> programs and checking btf id during program verification.
> Adding above functions to this list.
>
> Suggested-by: Alexei Starovoitov <ast@...nel.org>
> Signed-off-by: Jiri Olsa <jolsa@...nel.org>
> ---
> v2 changes:
> - drop check for EXT programs [Andrii]
>
> kernel/bpf/verifier.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 2579f6fbb5c3..42311e51ac71 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -13112,6 +13112,17 @@ int bpf_check_attach_target(struct bpf_verifier_log *log,
> return 0;
> }
>
> +BTF_SET_START(btf_id_deny)
> +BTF_ID_UNUSED
> +#ifdef CONFIG_SMP
> +BTF_ID(func, migrate_disable)
> +BTF_ID(func, migrate_enable)
> +#endif
> +#if !defined CONFIG_PREEMPT_RCU && !defined CONFIG_TINY_RCU
> +BTF_ID(func, rcu_read_unlock_strict)
> +#endif
> +BTF_SET_END(btf_id_deny)
I was wondering whether it makes sense to do this on pahole side instead ?
It can do more flexible regex matching and excluding all such functions
from vmlinux btf without the kernel having to do a maze of #ifdef
depending on config.
On one side we will lose BTF info about such functions, but what do we
need it for?
On the other side it will be a tiny reduction in vmlinux btf :)
Thoughts?
Powered by blists - more mailing lists