From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0600CC49361 for ; Tue, 15 Jun 2021 21:08:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DBEE7613B1 for ; Tue, 15 Jun 2021 21:08:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231344AbhFOVKf (ORCPT ); Tue, 15 Jun 2021 17:10:35 -0400 Received: from www62.your-server.de ([213.133.104.62]:50068 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231284AbhFOVKd (ORCPT ); Tue, 15 Jun 2021 17:10:33 -0400 Received: from sslproxy03.your-server.de ([88.198.220.132]) by www62.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1ltGIF-0004xO-Nz; Tue, 15 Jun 2021 23:08:19 +0200 Received: from [85.7.101.30] (helo=linux-3.home) by sslproxy03.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ltGIF-000CCY-9W; Tue, 15 Jun 2021 23:08:19 +0200 Subject: Re: [PATCH v5] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run To: Eric Biggers , Edward Cree Cc: Kurt Manucredo , syzbot+bed360704c521841c85d@syzkaller.appspotmail.com, keescook@chromium.org, yhs@fb.com, dvyukov@google.com, andrii@kernel.org, ast@kernel.org, bpf@vger.kernel.org, davem@davemloft.net, hawk@kernel.org, john.fastabend@gmail.com, kafai@fb.com, kpsingh@kernel.org, kuba@kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, songliubraving@fb.com, syzkaller-bugs@googlegroups.com, nathan@kernel.org, ndesaulniers@google.com, clang-built-linux@googlegroups.com, kernel-hardening@lists.openwall.com, kasan-dev@googlegroups.com References: <202106091119.84A88B6FE7@keescook> <752cb1ad-a0b1-92b7-4c49-bbb42fdecdbe@fb.com> <1aaa2408-94b9-a1e6-beff-7523b66fe73d@fb.com> <202106101002.DF8C7EF@keescook> <85536-177443-curtm@phaethon> From: Daniel Borkmann Message-ID: Date: Tue, 15 Jun 2021 23:08:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.103.2/26202/Tue Jun 15 13:21:24 2021) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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