[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b2aa5233-282e-004c-1ba3-63417cbccd58@iogearbox.net>
Date: Tue, 1 Mar 2022 00:53:34 +0100
From: Daniel Borkmann <daniel@...earbox.net>
To: Tiezhu Yang <yangtiezhu@...ngson.cn>,
Alexei Starovoitov <ast@...nel.org>,
Andrii Nakryiko <andrii@...nel.org>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>
Cc: Xuefeng Li <lixuefeng@...ngson.cn>, netdev@...r.kernel.org,
bpf@...r.kernel.org, linux-kernel@...r.kernel.org,
Johan Almbladh <johan.almbladh@...finetworks.com>
Subject: Re: [PATCH bpf-next v3 2/2] bpf: Make BPF_JIT_DEFAULT_ON selectable
in Kconfig
Hi Tiezhu,
(patch 1/2 applied so far, thanks!)
On 2/22/22 10:57 AM, Tiezhu Yang wrote:
> Currently, only x86, arm64 and s390 select ARCH_WANT_DEFAULT_BPF_JIT,
> the other archs do not select ARCH_WANT_DEFAULT_BPF_JIT. On the archs
> without ARCH_WANT_DEFAULT_BPF_JIT, if we want to set bpf_jit_enable to
> 1 by default, the only way is to enable CONFIG_BPF_JIT_ALWAYS_ON, then
> the users can not change it to 0 or 2, it seems bad for some users. We
Can you elaborate on the "it seems bad for some users" part? What's the concrete
use case? Also, why not add (e.g. mips) JIT to ARCH_WANT_DEFAULT_BPF_JIT if the
CI suite passes with high degree/confidence?
> can select ARCH_WANT_DEFAULT_BPF_JIT for those archs if it is proper,
> but at least for now, make BPF_JIT_DEFAULT_ON selectable can give them
> a chance.
>
> Additionally, with this patch, under !BPF_JIT_ALWAYS_ON, we can disable
> BPF_JIT_DEFAULT_ON on the archs with ARCH_WANT_DEFAULT_BPF_JIT when make
> menuconfig, it seems flexible for some developers.
>
> Signed-off-by: Tiezhu Yang <yangtiezhu@...ngson.cn>
> ---
> kernel/bpf/Kconfig | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig
> index f3db15a..8521874 100644
> --- a/kernel/bpf/Kconfig
> +++ b/kernel/bpf/Kconfig
> @@ -54,6 +54,7 @@ config BPF_JIT
> config BPF_JIT_ALWAYS_ON
> bool "Permanently enable BPF JIT and remove BPF interpreter"
> depends on BPF_SYSCALL && HAVE_EBPF_JIT && BPF_JIT
> + select BPF_JIT_DEFAULT_ON
Is the above needed if ...
> help
> Enables BPF JIT and removes BPF interpreter to avoid speculative
> execution of BPF instructions by the interpreter.
> @@ -63,8 +64,16 @@ config BPF_JIT_ALWAYS_ON
> failure.
>
> config BPF_JIT_DEFAULT_ON
> - def_bool ARCH_WANT_DEFAULT_BPF_JIT || BPF_JIT_ALWAYS_ON
> - depends on HAVE_EBPF_JIT && BPF_JIT
> + bool "Enable BPF JIT by default"
> + default y if ARCH_WANT_DEFAULT_BPF_JIT
... we retain the prior `default y if ARCH_WANT_DEFAULT_BPF_JIT || BPF_JIT_ALWAYS_ON` ?
> + depends on BPF_SYSCALL && HAVE_EBPF_JIT && BPF_JIT
Why is the extra BPF_SYSCALL dependency needed? You could still have this for cBPF->eBPF
translations when BPF syscall is compiled out (e.g. seccomp, sock/packet filters, etc).
> + help
> + Enables BPF JIT by default to avoid speculative execution of BPF
> + instructions by the interpreter.
> +
> + When CONFIG_BPF_JIT_DEFAULT_ON is enabled but CONFIG_BPF_JIT_ALWAYS_ON
> + is disabled, /proc/sys/net/core/bpf_jit_enable is set to 1 by default
> + and can be changed to 0 or 2.
>
> config BPF_UNPRIV_DEFAULT_OFF
> bool "Disable unprivileged BPF by default"
>
Powered by blists - more mailing lists