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 01C28ECAAA4 for ; Mon, 29 Aug 2022 18:08:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230008AbiH2SIW (ORCPT ); Mon, 29 Aug 2022 14:08:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49692 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229532AbiH2SIW (ORCPT ); Mon, 29 Aug 2022 14:08:22 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7043E8A6D3; Mon, 29 Aug 2022 11:08:21 -0700 (PDT) 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 0E69961329; Mon, 29 Aug 2022 18:08:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 49751C433D6; Mon, 29 Aug 2022 18:08:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1661796500; bh=h41PGKQB9pe7pe7VyewCaeAHUyzSkkZqPJT6d53vlas=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PQIJM+CIH2z7ZKFBpr8qKbXq6K/s7cUzt0xjb2LDDtMydJCn1LULT+0J/eTO8Dt8o V2fkODXOq1xIJ/RPfEnq/dZ1aBNLyuo7G574J8g3pf+dU3RYCMii0txmwPp/KQJLr9 iOV9M+RJyZRDF+Rh2fXBgcsUEZl0VhBMeOT/gv2TVhyCj7Jjft5DNztnpXDYd9KhHH Alg9PzPSmPM3eoNZ4cohMvxmlcJTtCG4dAYfPqt04Pd+PhbMOm8Uxl1s+VhqIC6VKI WF/pmCD6WHGwEzAU3R53YV2gGHIJ2+odLpC9gDNHngd8HVnKYJ9zVMLmeQ2vgz2FF5 IhPc/JGj6NQ1A== Date: Mon, 29 Aug 2022 18:08:07 +0000 From: Eric Biggers To: "Jason A. Donenfeld" Cc: x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Adam Langley , Ard Biesheuvel Subject: Re: Should Linux set the new constant-time mode CPU flags? Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Mon, Aug 29, 2022 at 12:39:53PM -0400, Jason A. Donenfeld wrote: > Hi Eric, > > On Thu, Aug 25, 2022 at 11:15:58PM +0000, Eric Biggers wrote: > > 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 > > Maybe it should be set unconditionally now, until we figure out how to > make it more granular. > > In terms of granularity, I saw other folks suggesting making it per-task > (so, presumably, a prctl() knob), and others mentioning doing it just > for kernel crypto. For the latter, I guess the crypto API could set it > inside of its abstractions, and the various lib/crypto APIs could set it > at invocation time. I wonder, though, what's the cost of > enabling/disabling it? Would we in fact need a kind of lazy-deferred > disabling, like we have with kernel_fpu_end()? I also wonder what > crypto-adjacent code might wind up being missed if we're going function > by function. Like, obviously we'd set this for crypto_memneq, but what > about potential unprotected `==` of ID numbers that could leak some info > in various protocols? What other subtle nearby code should we be > thinking about, that relies on constant time logic but isn't neatly > folded inside a crypto_do_something() function? > I'd much prefer it being set unconditionally by default as well, as making everyone (both kernel and userspace) turn it on and off constantly would be a nightmare. Note that Intel's documentation says that CPUs before Ice Lake behave as if DOITM is always set: "For Intel® Core™ family processors based on microarchitectures before Ice Lake and Intel Atom® family processors based on microarchitectures before Gracemont that do not enumerate IA32_UARCH_MISC_CTL, developers may assume that the instructions listed here operate as if DOITM is enabled." (It's a bit ambiguous, as it leaves the door open to IA32_UARCH_MISC_CTL being retroactively added to old CPUs. But I assume that hasn't actually happened.) So I think the logical approach is to unconditionally set DOITM by default, to fix this CPU bug in Ice Lake and later and just bring things back to the way they were in CPUs before Ice Lake. With that as a baseline, we can then discuss whether it's useful to provide ways to re-enable this CPU bug / "feature", for people who want to get the performance boost (if one actually exists) of data dependent timing after carefully assessing the risks. The other way around, of making everything insecure by default, seems like a really bad idea. - 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 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 593C7ECAAA4 for ; Mon, 29 Aug 2022 18:09:39 +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=95mqfIaf0YEgW2tYtU3u4LgfXuujAiOXEyS9CTxpO2k=; b=QXrGLB/I6Wr7dV jogPTiAJ/NtjzNmLa4asUh1cdx7RDHuJiYJfeBYAyyb7rL/R25itXQxcAvARkuQD4jMSsW/dAEaJl DMCuUggXG8daWBXRbZMB3qbTwPx7mSJovYfbh0nMPcoHfdTAUhfsG8hHO8eTkO12vUshq3h82OGn4 Q24oMWRsEutgOEpI6FMzlMN76fHIDv/Cg1YHK6TzwKVMr5BJdL0A8yxrAgXM/zAwHlnscTqyiNO78 CL0/eYQDT7FNWpSiIto9EHLLDjrLYi5LIvDnWeo+v1grXbJUoTRkMxlIwWhPw4qx3GXD0dWQSKvu7 +6NkJlIIzdjM1mdvjaNw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oSjBU-00CAMW-0O; Mon, 29 Aug 2022 18:08:28 +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 1oSjBO-00CAKn-MJ for linux-arm-kernel@lists.infradead.org; Mon, 29 Aug 2022 18:08:24 +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 081896130A; Mon, 29 Aug 2022 18:08:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 49751C433D6; Mon, 29 Aug 2022 18:08:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1661796500; bh=h41PGKQB9pe7pe7VyewCaeAHUyzSkkZqPJT6d53vlas=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PQIJM+CIH2z7ZKFBpr8qKbXq6K/s7cUzt0xjb2LDDtMydJCn1LULT+0J/eTO8Dt8o V2fkODXOq1xIJ/RPfEnq/dZ1aBNLyuo7G574J8g3pf+dU3RYCMii0txmwPp/KQJLr9 iOV9M+RJyZRDF+Rh2fXBgcsUEZl0VhBMeOT/gv2TVhyCj7Jjft5DNztnpXDYd9KhHH Alg9PzPSmPM3eoNZ4cohMvxmlcJTtCG4dAYfPqt04Pd+PhbMOm8Uxl1s+VhqIC6VKI WF/pmCD6WHGwEzAU3R53YV2gGHIJ2+odLpC9gDNHngd8HVnKYJ9zVMLmeQ2vgz2FF5 IhPc/JGj6NQ1A== Date: Mon, 29 Aug 2022 18:08:07 +0000 From: Eric Biggers To: "Jason A. Donenfeld" Cc: x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Adam Langley , Ard Biesheuvel Subject: Re: Should Linux set the new constant-time mode CPU flags? Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220829_110822_847406_83839AB9 X-CRM114-Status: GOOD ( 27.34 ) 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="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gTW9uLCBBdWcgMjksIDIwMjIgYXQgMTI6Mzk6NTNQTSAtMDQwMCwgSmFzb24gQS4gRG9uZW5m ZWxkIHdyb3RlOgo+IEhpIEVyaWMsCj4gCj4gT24gVGh1LCBBdWcgMjUsIDIwMjIgYXQgMTE6MTU6 NThQTSArMDAwMCwgRXJpYyBCaWdnZXJzIHdyb3RlOgo+ID4gSSdtIHdvbmRlcmluZyBpZiBwZW9w bGUgYXJlIGF3YXJlIG9mIHRoaXMgaXNzdWUsIGFuZCB3aGV0aGVyIGFueW9uZSBoYXMgYW55Cj4g PiB0aG91Z2h0cyBvbiB3aGV0aGVyL3doZXJlIHRoZSBrZXJuZWwgc2hvdWxkIGJlIHNldHRpbmcg dGhlc2UgbmV3IENQVSBmbGFncy4KPiA+IFRoZXJlIGRvbid0IGFwcGVhciB0byBoYXZlIGJlZW4g YW55IHByaW9yIGRpc2N1c3Npb25zIGFib3V0IHRoaXMuICAoVGhhbmtzIHRvCj4gCj4gTWF5YmUg aXQgc2hvdWxkIGJlIHNldCB1bmNvbmRpdGlvbmFsbHkgbm93LCB1bnRpbCB3ZSBmaWd1cmUgb3V0 IGhvdyB0bwo+IG1ha2UgaXQgbW9yZSBncmFudWxhci4KPiAKPiBJbiB0ZXJtcyBvZiBncmFudWxh cml0eSwgSSBzYXcgb3RoZXIgZm9sa3Mgc3VnZ2VzdGluZyBtYWtpbmcgaXQgcGVyLXRhc2sKPiAo c28sIHByZXN1bWFibHksIGEgcHJjdGwoKSBrbm9iKSwgYW5kIG90aGVycyBtZW50aW9uaW5nIGRv aW5nIGl0IGp1c3QKPiBmb3Iga2VybmVsIGNyeXB0by4gRm9yIHRoZSBsYXR0ZXIsIEkgZ3Vlc3Mg dGhlIGNyeXB0byBBUEkgY291bGQgc2V0IGl0Cj4gaW5zaWRlIG9mIGl0cyBhYnN0cmFjdGlvbnMs IGFuZCB0aGUgdmFyaW91cyBsaWIvY3J5cHRvIEFQSXMgY291bGQgc2V0IGl0Cj4gYXQgaW52b2Nh dGlvbiB0aW1lLiBJIHdvbmRlciwgdGhvdWdoLCB3aGF0J3MgdGhlIGNvc3Qgb2YKPiBlbmFibGlu Zy9kaXNhYmxpbmcgaXQ/IFdvdWxkIHdlIGluIGZhY3QgbmVlZCBhIGtpbmQgb2YgbGF6eS1kZWZl cnJlZAo+IGRpc2FibGluZywgbGlrZSB3ZSBoYXZlIHdpdGgga2VybmVsX2ZwdV9lbmQoKT8gSSBh bHNvIHdvbmRlciB3aGF0Cj4gY3J5cHRvLWFkamFjZW50IGNvZGUgbWlnaHQgd2luZCB1cCBiZWlu ZyBtaXNzZWQgaWYgd2UncmUgZ29pbmcgZnVuY3Rpb24KPiBieSBmdW5jdGlvbi4gTGlrZSwgb2J2 aW91c2x5IHdlJ2Qgc2V0IHRoaXMgZm9yIGNyeXB0b19tZW1uZXEsIGJ1dCB3aGF0Cj4gYWJvdXQg cG90ZW50aWFsIHVucHJvdGVjdGVkIGA9PWAgb2YgSUQgbnVtYmVycyB0aGF0IGNvdWxkIGxlYWsg c29tZSBpbmZvCj4gaW4gdmFyaW91cyBwcm90b2NvbHM/IFdoYXQgb3RoZXIgc3VidGxlIG5lYXJi eSBjb2RlIHNob3VsZCB3ZSBiZQo+IHRoaW5raW5nIGFib3V0LCB0aGF0IHJlbGllcyBvbiBjb25z dGFudCB0aW1lIGxvZ2ljIGJ1dCBpc24ndCBuZWF0bHkKPiBmb2xkZWQgaW5zaWRlIGEgY3J5cHRv X2RvX3NvbWV0aGluZygpIGZ1bmN0aW9uPwo+IAoKSSdkIG11Y2ggcHJlZmVyIGl0IGJlaW5nIHNl dCB1bmNvbmRpdGlvbmFsbHkgYnkgZGVmYXVsdCBhcyB3ZWxsLCBhcyBtYWtpbmcKZXZlcnlvbmUg KGJvdGgga2VybmVsIGFuZCB1c2Vyc3BhY2UpIHR1cm4gaXQgb24gYW5kIG9mZiBjb25zdGFudGx5 IHdvdWxkIGJlIGEKbmlnaHRtYXJlLgoKTm90ZSB0aGF0IEludGVsJ3MgZG9jdW1lbnRhdGlvbiBz YXlzIHRoYXQgQ1BVcyBiZWZvcmUgSWNlIExha2UgYmVoYXZlIGFzIGlmCkRPSVRNIGlzIGFsd2F5 cyBzZXQ6CgogICAgIkZvciBJbnRlbMKuIENvcmXihKIgZmFtaWx5IHByb2Nlc3NvcnMgYmFzZWQg b24gbWljcm9hcmNoaXRlY3R1cmVzIGJlZm9yZSBJY2UKICAgIExha2UgYW5kIEludGVsIEF0b23C riBmYW1pbHkgcHJvY2Vzc29ycyBiYXNlZCBvbiBtaWNyb2FyY2hpdGVjdHVyZXMgYmVmb3JlCiAg ICBHcmFjZW1vbnQgdGhhdCBkbyBub3QgZW51bWVyYXRlIElBMzJfVUFSQ0hfTUlTQ19DVEwsIGRl dmVsb3BlcnMgbWF5IGFzc3VtZQogICAgdGhhdCB0aGUgaW5zdHJ1Y3Rpb25zIGxpc3RlZCBoZXJl IG9wZXJhdGUgYXMgaWYgRE9JVE0gaXMgZW5hYmxlZC4iCgooSXQncyBhIGJpdCBhbWJpZ3VvdXMs IGFzIGl0IGxlYXZlcyB0aGUgZG9vciBvcGVuIHRvIElBMzJfVUFSQ0hfTUlTQ19DVEwgYmVpbmcK cmV0cm9hY3RpdmVseSBhZGRlZCB0byBvbGQgQ1BVcy4gIEJ1dCBJIGFzc3VtZSB0aGF0IGhhc24n dCBhY3R1YWxseSBoYXBwZW5lZC4pCgpTbyBJIHRoaW5rIHRoZSBsb2dpY2FsIGFwcHJvYWNoIGlz IHRvIHVuY29uZGl0aW9uYWxseSBzZXQgRE9JVE0gYnkgZGVmYXVsdCwgdG8KZml4IHRoaXMgQ1BV IGJ1ZyBpbiBJY2UgTGFrZSBhbmQgbGF0ZXIgYW5kIGp1c3QgYnJpbmcgdGhpbmdzIGJhY2sgdG8g dGhlIHdheQp0aGV5IHdlcmUgaW4gQ1BVcyBiZWZvcmUgSWNlIExha2UuICBXaXRoIHRoYXQgYXMg YSBiYXNlbGluZSwgd2UgY2FuIHRoZW4gZGlzY3Vzcwp3aGV0aGVyIGl0J3MgdXNlZnVsIHRvIHBy b3ZpZGUgd2F5cyB0byByZS1lbmFibGUgdGhpcyBDUFUgYnVnIC8gImZlYXR1cmUiLCBmb3IKcGVv cGxlIHdobyB3YW50IHRvIGdldCB0aGUgcGVyZm9ybWFuY2UgYm9vc3QgKGlmIG9uZSBhY3R1YWxs eSBleGlzdHMpIG9mIGRhdGEKZGVwZW5kZW50IHRpbWluZyBhZnRlciBjYXJlZnVsbHkgYXNzZXNz aW5nIHRoZSByaXNrcy4KClRoZSBvdGhlciB3YXkgYXJvdW5kLCBvZiBtYWtpbmcgZXZlcnl0aGlu ZyBpbnNlY3VyZSBieSBkZWZhdWx0LCBzZWVtcyBsaWtlIGEKcmVhbGx5IGJhZCBpZGVhLgoKLSBF cmljCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51 eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVh ZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1h cm0ta2VybmVsCg==