On 03/01/2022 07:53 AM, Daniel Borkmann wrote:
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
Hi Daniel,
Sorry for the late reply.
I saw the following two similar patches, some users want to set
bpf_jit_enable to 1 by default, at the same time, they want to
change it to 0 or 2 to debug, only enable CONFIG_BPF_JIT_DEFAULT_ON
is a proper way in such a case.
[PATCH bpf-next] bpf: trace jit code when enable BPF_JIT_ALWAYS_ON
https://lore.kernel.org/bpf/20210326124030.1138964-1-Jianlin.Lv@xxxxxxx/
[PATCH bpf-next] bpf: support bpf_jit_enable=2 for CONFIG_BPF_JIT_ALWAYS_ON
https://lore.kernel.org/bpf/20211231153550.3807430-1-houtao1@xxxxxxxxxx/
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?
Yes, we can let the specific arch select ARCH_WANT_DEFAULT_BPF_JIT in
Kconfig, this commit only gives another chance to enable or disable
CONFIG_BPF_JIT_DEFAULT_ON manually when make menuconfig, this is useful
to debug when develop JIT.
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@xxxxxxxxxxx>
---
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` ?
After add
bool "Enable BPF JIT by default"
if use
default y if ARCH_WANT_DEFAULT_BPF_JIT || BPF_JIT_ALWAYS_ON
under !ARCH_WANT_DEFAULT_BPF_JIT, when enable CONFIG_BPF_JIT_ALWAYS_ON
manually through make menuconfig, CONFIG_BPF_JIT_DEFAULT_ON is not set
automatically, it seems not reasonable, but I do not know the reason,
maybe this is because CONFIG_BPF_JIT_ALWAYS_ON is user selectable rather
than selected via Kconfig only (like ARCH_WANT_DEFAULT_BPF_JIT), so here
let BPF_JIT_ALWAYS_ON select BPF_JIT_DEFAULT_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).
Sorry, just copy-paste from "config BPF_JIT_ALWAYS_ON".
If BPF_SYSCALL dependency is not needed by BPF_JIT_DEFAULT_ON,
should we remove BPF_SYSCALL dependency in "config BPF_JIT_ALWAYS_ON"?
Thanks,
Tiezhu
+ 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"
