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,URIBL_BLOCKED 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 5650EC48BD1 for ; Thu, 10 Jun 2021 20:00:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 35DDD61414 for ; Thu, 10 Jun 2021 20:00:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230356AbhFJUCp (ORCPT ); Thu, 10 Jun 2021 16:02:45 -0400 Received: from mail.kernel.org ([198.145.29.99]:36206 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230188AbhFJUCn (ORCPT ); Thu, 10 Jun 2021 16:02:43 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 2DAEC613F1; Thu, 10 Jun 2021 20:00:46 +0000 (UTC) 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: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 D3A46C48BE0 for ; Thu, 10 Jun 2021 20:00:51 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 78EEC61419 for ; Thu, 10 Jun 2021 20:00:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 78EEC61419 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-kernel-mentees-bounces@lists.linuxfoundation.org Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 3919F83DD5; Thu, 10 Jun 2021 20:00:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GT2nyEdmvbcC; Thu, 10 Jun 2021 20:00:50 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp1.osuosl.org (Postfix) with ESMTPS id 87F2383DD3; Thu, 10 Jun 2021 20:00:50 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5C7ADC000D; Thu, 10 Jun 2021 20:00:50 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 76241C000B for ; Thu, 10 Jun 2021 20:00:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 5B5564066E for ; Thu, 10 Jun 2021 20:00:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=kernel.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2Q9McFbknT3 for ; Thu, 10 Jun 2021 20:00:47 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp4.osuosl.org (Postfix) with ESMTPS id A46514066D for ; Thu, 10 Jun 2021 20:00:47 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 2DAEC613F1; Thu, 10 Jun 2021 20:00:46 +0000 (UTC) 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 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-Disposition: inline In-Reply-To: Cc: Song Liu , Kernel Hardening , Alexei Starovoitov , Jesper Dangaard Brouer , syzbot+bed360704c521841c85d@syzkaller.appspotmail.com, Daniel Borkmann , John Fastabend , Andrii Nakryiko , kasan-dev , Clang-Built-Linux ML , Jakub Kicinski , linux-kernel-mentees@lists.linuxfoundation.org, Kees Cook , syzkaller-bugs , KP Singh , nathan@kernel.org, Yonghong Song , Dmitry Vyukov , Network Development , Nick Desaulniers , LKML , "David S. Miller" , bpf , Martin KaFai Lau X-BeenThere: linux-kernel-mentees@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-kernel-mentees-bounces@lists.linuxfoundation.org Sender: "Linux-kernel-mentees" 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 _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees