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 77950ECAAA3 for ; Thu, 25 Aug 2022 23:17:20 +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: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:In-Reply-To:References: List-Owner; bh=cR9CYl4Ju8hmWPEZGTZmkkxHH5c4XxsAY1Oe8j476XQ=; b=RxAp/4umA8eao2 nbnO/QJmsh5qdQLrozN+oEVTerZrXfOgxhaVjGeAXQypLwCKCeyeUC2+qnEuertV1q00DWCz78VVa nWOlqRRgI/k/BR6BB0xnt32feKpJ0q1o+XqS6Q/Wb4B9qZY2MiNY/4LN7Jk3jy3LVj6zotJKXZ875 t+DYLHAfiEK93Wp/U1r5I7otW+XRGi2HL9b3YlOh4leDK7alIgN41SQxW9U50BGx5IUDyYGPuw3tE iJB8oVxuiLgxEQLV+swak8v+YQStyyIGTsbGk1Yh/wpxtV1PuV8+TFGMfHdJKC9dhI/FZ2Cm4wWt8 lgjFUsinNi2O0Jscuuvg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oRM53-0044do-Tp; Thu, 25 Aug 2022 23:16:10 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oRM4x-0044bD-7s for linux-arm-kernel@lists.infradead.org; Thu, 25 Aug 2022 23:16:07 +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 EDC0CB82EB4; Thu, 25 Aug 2022 23:16:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7C03C433D6; Thu, 25 Aug 2022 23:15:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1661469359; bh=1luF4ZPC+Q2s8FgZ5cg9kHsh/AqkmR9rbZevSu2GNpA=; h=Date:From:To:Cc:Subject:From; b=kEU9/E79AmW2kl0mXY5lSkYUcvS33J095SeGujFg01tLd9d1L5kFgZGRJf4pgZnA8 138aGBAHZD1O9j7zbDsYbd7xvMkrHgpG/MiGRV+GfZJMhufeurfEJPxm9xExsAhmNw NiRMiCxI0dPsv97n5JgeBuVX7pniCB0WGOmvX7M9KE5EFa5sr2RXag49NYLP/R/mBo zWod0WIE+510aCkPPJ9Zgxg9hJ3Ph/p7Ric9PURdl/qkGNYLHLxU2I3LkMCynaShDA RdlJtC7P2qHUDNcdLbw/r1pbYfyK19VvLF/0Q9lCze30CRPu7Pir5egKUMcXU2RGif PrIaMimUzM3AA== Date: Thu, 25 Aug 2022 23:15:58 +0000 From: Eric Biggers To: x86@kernel.org, linux-arm-kernel@lists.infradead.org Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Adam Langley , "Jason A. Donenfeld" , Ard Biesheuvel Subject: Should Linux set the new constant-time mode CPU flags? Message-ID: MIME-Version: 1.0 Content-Disposition: inline X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220825_161603_479355_B7F249AF X-CRM114-Status: GOOD ( 15.05 ) 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 Hi, Intel and ARM recently published documentation that says that no instructions are guaranteed to be constant-time with respect to their data operands, unless a "data independent timing" flag in the IA32_UARCH_MISC_CTL register (Intel) or DIT register (arm64) is set: * https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/data-operand-independent-timing-isa-guidance.html * https://developer.arm.com/documentation/ddi0595/2021-06/AArch64-Registers/DIT--Data-Independent-Timing This is a major problem for crypto code, which needs to be constant-time, especially with respect to keys. And since this is a CPU issue, it affects all code running on the CPU. While neither company is treating this as a security disclosure, to me this looks exactly like a CPU vulnerability. For Intel, given that the mitigation is to set an MSR flag, it seems that the kernel will need to do that -- similar to the MSR flags that enable mitigations for speculative execution vulnerabilities. For arm64, it's not clear to me whether the DIT flag is privileged or not. If privileged, I expect it would need to be set by the kernel just like the Intel flag. If unprivileged, I expect there will still be work to do in the kernel, as the flag will need to be set when running any crypto code in the kernel. I'm wondering if people are aware of this issue, and whether anyone has any thoughts on whether/where the kernel should be setting these new CPU flags. There don't appear to have been any prior discussions about this. (Thanks to Adam Langley, who maintains BoringSSL, for bringing this to my attention.) - Eric _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel