linux-kernel - Re: [PATCH bpf-next v3 2/2] bpf: Make BPF_JIT_DEFAULT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 9 Mar 2022 12:21:51 +0800
From:   Tiezhu Yang <yangtiezhu@...ngson.cn>
To:     Daniel Borkmann <daniel@...earbox.net>,
        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



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@arm.com/

[PATCH bpf-next] bpf: support bpf_jit_enable=2 for CONFIG_BPF_JIT_ALWAYS_ON
https://lore.kernel.org/bpf/20211231153550.3807430-1-houtao1@huawei.com/


> 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@...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` ?

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"
>>