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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91BF8C433F5 for ; Thu, 3 Mar 2022 11:16:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232685AbiCCLRR (ORCPT ); Thu, 3 Mar 2022 06:17:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55686 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231971AbiCCLRR (ORCPT ); Thu, 3 Mar 2022 06:17:17 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 09DE216E7F2 for ; Thu, 3 Mar 2022 03:16:32 -0800 (PST) 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 8F53C61689 for ; Thu, 3 Mar 2022 11:16:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA7C8C340EF; Thu, 3 Mar 2022 11:16:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646306191; bh=VUwkrK39WEvpiwdRpPCpjr3baRsJTQ1IDZXIQ/K1M9U=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=div/YSHjxwUWA2VHysN2fA/mtp6tv4HlTxEAV4ZRVoPTxWucZZoOoYooJ2wSsq5b1 bPEhM7NYFKzBJ5a5rtIusGYeFXIKTP7nGP0faWDCUmO5y3StnTnkVdStJqPIX2UeYT jNaDzGRUyxkN2blfsozEdbAQ0ue31GVfbQmyiPOCIZA4+aS2bHF6vre/RsqrS1FLzj HS4r5SZdOpFtA3V983XpavM1bRmLpTqS3T7gVY2Sl3tAtUa/ep0vwQ6z3mESTIco2D fIEwM/2EN5GYpOvwy+a4QEKDIhxn5VsnGzjTpcnQKYrS8vQ5lZuY6CQdy0EIQgdGNk qK02Xyv/Atw2A== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nPjRc-00BwFP-HH; Thu, 03 Mar 2022 11:16:28 +0000 Date: Thu, 03 Mar 2022 11:16:28 +0000 Message-ID: <87y21r1e2b.wl-maz@kernel.org> From: Marc Zyngier To: Mark Brown , Ard Biesheuvel Cc: Herbert Xu , "David S . Miller" , Catalin Marinas , Will Deacon , Linux Crypto Mailing List , Linux ARM Subject: Re: [PATCH] arm64: crypto: Don't allow v8.2 extensions to be used with BROKEN_GAS_INST In-Reply-To: References: <20220302165438.1140256-1-broonie@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: broonie@kernel.org, ardb@kernel.org, herbert@gondor.apana.org.au, davem@davemloft.net, catalin.marinas@arm.com, will@kernel.org, linux-crypto@vger.kernel.org, linux-arm-kernel@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Thu, 03 Mar 2022 07:26:45 +0000, Ard Biesheuvel wrote: > > On Wed, 2 Mar 2022 at 16:54, Mark Brown wrote: > > > > We support building the kernel with archaic versions of binutils which > > had some confusion regarding how instructions should be encoded for .inst > > which we work around with the __emit_inst() macro. Unfortunately we have > > not consistently used this macro, one of the places where it's missed being > > the macros that manually encode v8.2 crypto instructions. This means that > > kernels built with such toolchains have never supported use of the affected > > instructions correctly. > > > > Since these toolchains are very old (some idle research suggested 2015 > > era) it seems more sensible to just refuse to build v8.2 crypto support > > with them, in the unlikely event that someone has a need to use such a > > toolchain to build a kernel which will run on a system with v8.2 crypto > > support they can always fix this properly but it seems more likely that > > we will deprecate support for these toolchains and remove __emit_inst() > > before that happens. > > > > Signed-off-by: Mark Brown > > IIRC this is not about .inst getting the encoding wrong, but about > confusion over the size of the generated opcode, resulting in problems > generating constants involving relative offsets between labels. (The > endian swap is there so that .long can be used on BE to emit the LE > opcodes) > > This is not an issue here, so I don't think this change is necessary. Indeed. The only case where the broken GAS .inst has hit us was in combination with alternatives (see eb7c11ee3c5c for details). The encoding itself is always correct, and it is only the label generation that was broken. If we were affected by this, the kernel would simply fail to build with these toolchains. If this ever happens (because we'd add some extra alternative sequences to the crypto code?), we can revisit this. But in the meantime, I don't see anything warranting this extra dependency. Thanks, M. -- Without deviation from the norm, progress is not possible. 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 B1363C433F5 for ; Thu, 3 Mar 2022 11:17:54 +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:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=yqx4rqoPoiShwXiueJPnMEaBCudJBZsGPrtG7Kqt64M=; b=C8jZah8AwvxOar QC23gvKUJXSx+xY/TjeXYYTv5kXzkmFczUD3mRX669L5es092T5x7D+dXMhAqJN3EwXa9kZL7VRCi bNjxCd2/33/uPzRRNpj3DmJhkc1rZrIpvmH1inCrkss7dDe6ZK6/mk7v8vt9vMTi2om9WpYetFggI NBjHzHVLgqVGuHo/SU/ZyzULAycj0A/dafQ5Xtu2LBVjntU5UbifW3LaXRNqkZHHvsO9wrY+Jkpnx P8PzVVAFzR5U/rQmyjW5AZ8KyfOAykT1WuTGMBacLJkUg79JOqdVMAskgxl1pHyGQt2D18LLfeXbP QgMa4Ge2Dx/GNDUm+0jQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nPjRl-006BQq-I6; Thu, 03 Mar 2022 11:16:37 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nPjRh-006BQK-Kz for linux-arm-kernel@lists.infradead.org; Thu, 03 Mar 2022 11:16:35 +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 ams.source.kernel.org (Postfix) with ESMTPS id 4C594B824D8; Thu, 3 Mar 2022 11:16:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA7C8C340EF; Thu, 3 Mar 2022 11:16:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646306191; bh=VUwkrK39WEvpiwdRpPCpjr3baRsJTQ1IDZXIQ/K1M9U=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=div/YSHjxwUWA2VHysN2fA/mtp6tv4HlTxEAV4ZRVoPTxWucZZoOoYooJ2wSsq5b1 bPEhM7NYFKzBJ5a5rtIusGYeFXIKTP7nGP0faWDCUmO5y3StnTnkVdStJqPIX2UeYT jNaDzGRUyxkN2blfsozEdbAQ0ue31GVfbQmyiPOCIZA4+aS2bHF6vre/RsqrS1FLzj HS4r5SZdOpFtA3V983XpavM1bRmLpTqS3T7gVY2Sl3tAtUa/ep0vwQ6z3mESTIco2D fIEwM/2EN5GYpOvwy+a4QEKDIhxn5VsnGzjTpcnQKYrS8vQ5lZuY6CQdy0EIQgdGNk qK02Xyv/Atw2A== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nPjRc-00BwFP-HH; Thu, 03 Mar 2022 11:16:28 +0000 Date: Thu, 03 Mar 2022 11:16:28 +0000 Message-ID: <87y21r1e2b.wl-maz@kernel.org> From: Marc Zyngier To: Mark Brown , Ard Biesheuvel Cc: Herbert Xu , "David S . Miller" , Catalin Marinas , Will Deacon , Linux Crypto Mailing List , Linux ARM Subject: Re: [PATCH] arm64: crypto: Don't allow v8.2 extensions to be used with BROKEN_GAS_INST In-Reply-To: References: <20220302165438.1140256-1-broonie@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: broonie@kernel.org, ardb@kernel.org, herbert@gondor.apana.org.au, davem@davemloft.net, catalin.marinas@arm.com, will@kernel.org, linux-crypto@vger.kernel.org, linux-arm-kernel@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220303_031634_014801_2BB80461 X-CRM114-Status: GOOD ( 34.96 ) 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 Thu, 03 Mar 2022 07:26:45 +0000, Ard Biesheuvel wrote: > > On Wed, 2 Mar 2022 at 16:54, Mark Brown wrote: > > > > We support building the kernel with archaic versions of binutils which > > had some confusion regarding how instructions should be encoded for .inst > > which we work around with the __emit_inst() macro. Unfortunately we have > > not consistently used this macro, one of the places where it's missed being > > the macros that manually encode v8.2 crypto instructions. This means that > > kernels built with such toolchains have never supported use of the affected > > instructions correctly. > > > > Since these toolchains are very old (some idle research suggested 2015 > > era) it seems more sensible to just refuse to build v8.2 crypto support > > with them, in the unlikely event that someone has a need to use such a > > toolchain to build a kernel which will run on a system with v8.2 crypto > > support they can always fix this properly but it seems more likely that > > we will deprecate support for these toolchains and remove __emit_inst() > > before that happens. > > > > Signed-off-by: Mark Brown > > IIRC this is not about .inst getting the encoding wrong, but about > confusion over the size of the generated opcode, resulting in problems > generating constants involving relative offsets between labels. (The > endian swap is there so that .long can be used on BE to emit the LE > opcodes) > > This is not an issue here, so I don't think this change is necessary. Indeed. The only case where the broken GAS .inst has hit us was in combination with alternatives (see eb7c11ee3c5c for details). The encoding itself is always correct, and it is only the label generation that was broken. If we were affected by this, the kernel would simply fail to build with these toolchains. If this ever happens (because we'd add some extra alternative sequences to the crypto code?), we can revisit this. But in the meantime, I don't see anything warranting this extra dependency. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel