linux-kernel - Re: [PATCH v5] bpf: core: fix shift-out-of-bounds in ___bpf_prog

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 15 Jun 2021 23:08:18 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Eric Biggers <ebiggers@...nel.org>,
        Edward Cree <ecree.xilinx@...il.com>
Cc:     Kurt Manucredo <fuzzybritches0@...il.com>,
        syzbot+bed360704c521841c85d@...kaller.appspotmail.com,
        keescook@...omium.org, yhs@...com, dvyukov@...gle.com,
        andrii@...nel.org, ast@...nel.org, bpf@...r.kernel.org,
        davem@...emloft.net, hawk@...nel.org, john.fastabend@...il.com,
        kafai@...com, kpsingh@...nel.org, kuba@...nel.org,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        songliubraving@...com, syzkaller-bugs@...glegroups.com,
        nathan@...nel.org, ndesaulniers@...gle.com,
        clang-built-linux@...glegroups.com,
        kernel-hardening@...ts.openwall.com, kasan-dev@...glegroups.com
Subject: Re: [PATCH v5] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run

On 6/15/21 9:33 PM, Eric Biggers wrote:
> On Tue, Jun 15, 2021 at 07:51:07PM +0100, Edward Cree wrote:
>>
>> As I understand it, the UBSAN report is coming from the eBPF interpreter,
>>   which is the *slow path* and indeed on many production systems is
>>   compiled out for hardening reasons (CONFIG_BPF_JIT_ALWAYS_ON).
>> Perhaps a better approach to the fix would be to change the interpreter
>>   to compute "DST = DST << (SRC & 63);" (and similar for other shifts and
>>   bitnesses), thus matching the behaviour of most chips' shift opcodes.
>> This would shut up UBSAN, without affecting JIT code generation.
> 
> Yes, I suggested that last week
> (https://lkml.kernel.org/netdev/YMJvbGEz0xu9JU9D@gmail.com).  The AND will even
> get optimized out when compiling for most CPUs.

Did you check if the generated interpreter code for e.g. x86 is the same
before/after with that?

How does UBSAN detect this in general? I would assume generated code for
interpreter wrt DST = DST << SRC would not really change as otherwise all
valid cases would be broken as well, given compiler has not really room
to optimize or make any assumptions here, in other words, it's only
propagating potential quirks under such cases from underlying arch.

Thanks,
Daniel