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=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 C5F0FC48BDF for ; Thu, 10 Jun 2021 20:01:08 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id DAC37613F1 for ; Thu, 10 Jun 2021 20:01:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DAC37613F1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-21302-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 7467 invoked by uid 550); 10 Jun 2021 20:01:00 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Received: (qmail 7435 invoked from network); 10 Jun 2021 20:00:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623355247; bh=ZbRvzCT7wna4OsitGKZ+uEppwjq/LPjh5F/SwhxsvIw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=it1PG+R5MO443wIpHpOu52Wp7/yNhdoVxG8Ar5iSyJLybhL0qRCWf+X1Js86t3GNz 9X2d4POr6Z8djOs42/VuoWMyLaM3oTyaagYIzVmMRiM7EiynqhPxtfyTZqbFMR1rvo fxTtwWzLdXGGd+h9Rw06HuGpDATp4XLAcGwL6Je4gcJi8HU7Kpfs3Fm6l+jXisE8il I5SEZkaU3f/ZVbStLDvmwkO9oufSpN5FVnVmz4VCS5oEhuC4mJyGn3NidjN3qS32Zv DafKhl5qLVDFD/Ly7Wl6shQjosw6s8FsamH/AE+KynX1+5FNSagLp0VOQNAsTO+ceQ UCtSRuWwEEtsA== Date: Thu, 10 Jun 2021 13:00:44 -0700 From: Eric Biggers To: Alexei Starovoitov Cc: Kees Cook , Yonghong Song , Dmitry Vyukov , Kurt Manucredo , syzbot+bed360704c521841c85d@syzkaller.appspotmail.com, Andrii Nakryiko , Alexei Starovoitov , bpf , Daniel Borkmann , "David S. Miller" , Jesper Dangaard Brouer , John Fastabend , Martin KaFai Lau , KP Singh , Jakub Kicinski , LKML , Network Development , Song Liu , syzkaller-bugs , nathan@kernel.org, Nick Desaulniers , Clang-Built-Linux ML , linux-kernel-mentees@lists.linuxfoundation.org, Shuah Khan , Greg Kroah-Hartman , Kernel Hardening , kasan-dev Subject: Re: [PATCH v4] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run Message-ID: References: <87609-531187-curtm@phaethon> <6a392b66-6f26-4532-d25f-6b09770ce366@fb.com> <202106091119.84A88B6FE7@keescook> <752cb1ad-a0b1-92b7-4c49-bbb42fdecdbe@fb.com> <1aaa2408-94b9-a1e6-beff-7523b66fe73d@fb.com> <202106101002.DF8C7EF@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Jun 10, 2021 at 10:52:37AM -0700, Alexei Starovoitov wrote: > On Thu, Jun 10, 2021 at 10:06 AM Kees Cook wrote: > > > > > > I guess the main question: what should happen if a bpf program writer > > > > does _not_ use compiler nor check_shl_overflow()? > > > > I think the BPF runtime needs to make such actions defined, instead of > > doing a blind shift. It needs to check the size of the shift explicitly > > when handling the shift instruction. > > Such ideas were brought up in the past and rejected. > We're not going to sacrifice performance to make behavior a bit more > 'defined'. CPUs are doing it deterministically. What CPUs do is not the whole story. The compiler can assume that the shift amount is less than the width and use that assumption in other places, resulting in other things being miscompiled. Couldn't you just AND the shift amounts with the width minus 1? That would make the shifts defined, and the compiler would optimize out the AND on any CPU that interprets the shift amounts modulo the width anyway (e.g., x86). - Eric