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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1B4E5C433F5 for ; Fri, 21 Jan 2022 19:55:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=8dN0GoOSDm/VLBD1TCRQjiZsK3KHIqgKPTwKqHhYEgM=; b=BiD5V0UgcbCh2A eYOOgXSDN2j4wuS07FVLua2CoGzAAXlg5yQxw6RWRVaoL33NJ4kvPWWZba2D9iSnh1HG9HFrXTxqc capLBPRWN6jF2DfXOfLydGFEusYiG/Y0WPxl/xW0dch9zuVlAmScrPH6u1m8fbqWbxXTM5C+JP2t5 WCOBmMnvAvQ/bf4Hols8EaBdF+QvUapfv4JINYpsclFbXAchDz6UdlEqw5boF9LDGqpFOeTo6PuL5 VmziunOD82cmI5+KV1tGAwwCWSUBGUuDg1FkDYxg6VG0HdZGYgN4YDGN46Sk1TtALWPiShd+FDCjW TchvF6P7GaTnNuGVs0Gw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nAzzd-00G0OJ-GX; Fri, 21 Jan 2022 19:54:41 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nAzza-00G0Ng-1R; Fri, 21 Jan 2022 19:54:39 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 0FD34616EF; Fri, 21 Jan 2022 19:54:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 35DD7C340E1; Fri, 21 Jan 2022 19:54:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1642794876; bh=C7b5I+hDM3u7jSdl9XELS34WhxUJsTVhZpt6j4FOljY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ku+dDBqU5FvjVhQAUwJ24NyoqaB9BmTN50WqAoLXPhIDErCUpb6iXh0yhnNIj1ML9 pne49JGIv7tFU/QDlVdMMeVRipgZWMnd67hUneYHAB57k5YHJ9nhEbQebIibrEMUrq h8gyKdCrl7wHd+xg7irdV2DOEkgCo+ZTsMeuuK6IuU6VQDGAEGlLtpzuDxMSWlEXrU UsUMsl7LTdkehHltiyy2bF3I0QiEk0N7Pe52UrgefBw7FnSihS9nZ1jEw31z8T/SLv rXov9H2AOhSV/kjJsLS308OGUhGcii4PEYeTLgZAwd/Utk7M0zBCOWIx4oMEnDtJ3a 34u/wpZwmRtWQ== Date: Fri, 21 Jan 2022 11:54:34 -0800 From: Eric Biggers To: "Jason A. Donenfeld" Cc: Miles Chen , Ard Biesheuvel , Linux ARM , Linux Crypto Mailing List , Linux Kernel Mailing List , linux-mediatek@lists.infradead.org, Nick Desaulniers , Sami Tolvanen Subject: Re: [PATCH] lib/crypto: blake2s: avoid indirect calls to compression function for Clang CFI Message-ID: References: <20220119135450.564115-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220119135450.564115-1-Jason@zx2c4.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220121_115438_204180_5CF6AD31 X-CRM114-Status: GOOD ( 20.73 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 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 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jan 19, 2022 at 02:54:50PM +0100, Jason A. Donenfeld wrote: > blake2s_compress_generic is weakly aliased to blake2s_generic. The > current harness for function selection uses a function pointer, which is > ordinarily inlined and resolved at compile time. But when Clang's CFI is > enabled, CFI still triggers when making an indirect call via a weak > symbol. This seems like a bug in Clang's CFI, as though it's bucketing > weak symbols and strong symbols differently. It also only seems to > trigger when "full LTO" mode is used, rather than "thin LTO". > > [ 0.000000][ T0] Kernel panic - not syncing: CFI failure (target: blake2s_compress_generic+0x0/0x1444) > [ 0.000000][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-mainline-06981-g076c855b846e #1 > [ 0.000000][ T0] Hardware name: MT6873 (DT) > [ 0.000000][ T0] Call trace: > [ 0.000000][ T0] dump_backtrace+0xfc/0x1dc > [ 0.000000][ T0] dump_stack_lvl+0xa8/0x11c > [ 0.000000][ T0] panic+0x194/0x464 > [ 0.000000][ T0] __cfi_check_fail+0x54/0x58 > [ 0.000000][ T0] __cfi_slowpath_diag+0x354/0x4b0 > [ 0.000000][ T0] blake2s_update+0x14c/0x178 > [ 0.000000][ T0] _extract_entropy+0xf4/0x29c > [ 0.000000][ T0] crng_initialize_primary+0x24/0x94 > [ 0.000000][ T0] rand_initialize+0x2c/0x6c > [ 0.000000][ T0] start_kernel+0x2f8/0x65c > [ 0.000000][ T0] __primary_switched+0xc4/0x7be4 > [ 0.000000][ T0] Rebooting in 5 seconds.. > > Nonetheless, the function pointer method isn't so terrific anyway, so > this patch replaces it with a simple boolean, which also gets inlined > away. This successfully works around the Clang bug. > > In general, I'm not too keen on all of the indirection involved here; it > clearly does more harm than good. Hopefully the whole thing can get > cleaned up down the road when lib/crypto is overhauled more > comprehensively. But for now, we go with a simple bandaid. > > Fixes: 6048fdcc5f26 ("lib/crypto: blake2s: include as built-in") > Reported-by: Miles Chen > Cc: Nick Desaulniers > Cc: Sami Tolvanen > Cc: Ard Biesheuvel > Signed-off-by: Jason A. Donenfeld > --- > arch/arm/crypto/blake2s-shash.c | 4 ++-- > arch/x86/crypto/blake2s-shash.c | 4 ++-- > crypto/blake2s_generic.c | 4 ++-- > include/crypto/internal/blake2s.h | 36 ++++++++++++++++++------------- > lib/crypto/blake2s.c | 4 ++-- > 5 files changed, 29 insertions(+), 23 deletions(-) There are some lines over 80 columns in this patch. Otherwise this looks fine. It would be really nice to fix this in clang, though. - Eric _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel