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 F2196ECAAA3 for ; Fri, 26 Aug 2022 08:51:45 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=FjI1Pi9MVY917bPUDhOpdHYmwk7amXoCJyJf+3f7mOg=; b=uD3+M5ENJ254qz 392uYs03rViOhlsJS2WYJ00b5Rbn3UFt4Oi5aiFAKnIKqtqHHiR5JOnwEPHdkxochrXSPK2peNF9R 0zJGjU6Mb2F1bF24B1Oqe7BAbDA6tlpIsOZI1VLDizmhXFRMqHFYxPCtfLPImp4AmeZWgdcOP5Xoa 9XOm+v+El1zt8AdSsme7NptrH6+ZTEzZ9sL8Zk6WKi2vyIk3ROkxbXdnsp/YiktlAqsCbMhorn8QH 3lu1WncXq9Ha0o7p1q3ZzaxnEdBcIUEZEq2FrYn99fbSJGQmtoIEJPGXb/O1+PstdxeFagptTn8cN gnvurP/D7nm+mDqV83sA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oRV2z-00HNWg-Ed; Fri, 26 Aug 2022 08:50:37 +0000 Received: from mout.kundenserver.de ([212.227.126.131]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oRV2t-00HNUG-5e for linux-arm-kernel@lists.infradead.org; Fri, 26 Aug 2022 08:50:32 +0000 Received: from mail-ej1-f51.google.com ([209.85.218.51]) by mrelayeu.kundenserver.de (mreue012 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MUl4z-1osHB70CkD-00QmLm for ; Fri, 26 Aug 2022 10:45:24 +0200 Received: by mail-ej1-f51.google.com with SMTP id tl26so1128067ejc.9 for ; Fri, 26 Aug 2022 01:45:23 -0700 (PDT) X-Gm-Message-State: ACgBeo1sFtYsoWRRUh7WwL6W3NCyRvEUJxyasPHgYE5UeB1A1+koR5qa xp7cSCO0r0pJJw9Dym5C5jY2sEoaRhx47JcEcj0= X-Google-Smtp-Source: AA6agR6rhA0U++DrfPtjQ5ooNZ/yKGtZYIy6GJv0mHxh03+9mAoj11Jd7qH4DYueP/o4Zfu5g9vzB6C+5LWRmCcuVk0= X-Received: by 2002:a17:907:7610:b0:73d:afe8:9837 with SMTP id jx16-20020a170907761000b0073dafe89837mr4876186ejc.606.1661503523457; Fri, 26 Aug 2022 01:45:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Arnd Bergmann Date: Fri, 26 Aug 2022 10:45:07 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Should Linux set the new constant-time mode CPU flags? To: Eric Biggers Cc: x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Adam Langley , "Jason A. Donenfeld" , Ard Biesheuvel X-Provags-ID: V03:K1:mKp2RPfPYf0ZmGqbHOHSH6tNAsF8eklGUlUKwnYz9WdZMrilLKz nchH46IUzcxSJePaUmLUzNRFXNrPIhH0c3wOWWRV5iFT4HmTYv5KZbaOfML+oSs7k/0XhCf CKHQPPg9Km04D1z8n+53th7nSlE4+aUGagEHJw1n+xEwECWj7A7CspuhOjQGoe7gOEfpezv mcCn2fWe0bjzUjVk1P05g== X-UI-Out-Filterresults: notjunk:1;V03:K0:bIYnHr3vJXg=:yREfrDd/nNfHYAolqU6pl4 /QcgjHOPD/qkixg2p2R6FrGkyMnKUQ5jBRyFRJdWNTiPBJstc4IXvpd1W/rjgdMQRURG33boW NraGX/3xUbzSW+nSOwGFPQ3uwWUvnXsSOca/qaqWVSBlrwgMJVfhj/YiprfuGeqtTRWZ08eXV k1LyRQZF8PTJR4rjdBnQjLsZ1/4FSHSd0USdT6W1au9eAvbBOKx2kP4147AvIJ6LZldUeoh36 arPq2GCdjUqHmkdV85K7tuZLBPbyVR5DktrkUpsv+blrh3bri73zVDrz70RWbX5/LPAIYwoKA uyLrCEVqb0zmoE0zryYZUOrjT89LcjZDq28CCnxc6VZopLyLByXPDKEQcf1fS8tBcyV0WMOgI eg6bMDl7NsIdNiDjbTycpXoCy7/DLLGNClx2aAzgcOfGykr3OLtwQ/2EKIOSqyByiViFkFEUI +wjyzY82ga/0kcuHx2XMoOTyrE0XE9lGyrJLrF/GuiWqs5ULet5h7ORLOLE9Eb1itJKix7C1T f9Po7i0uM4rfgHo0eDIMrKRcrEMwgKwKQJfiO25b6gt1DK4hYjUay1US3mDLHM8bqbNdTHUaQ sz5Tzxy1kfFrbPFABZ+NbCgfOo5u1QMAcwUoIHlrzhtpGzyrUSi2X8zEn/oC6N5Rs6GgGt+OI JCIceOPK12esswg/GvmXQErq2ZQx90nfspcPrTImWXxYpNnQhZ0Jij/LP6lGFhmwR00towJXS mScYKJFeR+hJk7v7KM+JDD8f00Gs0T5KK74vuq2WbNdNbRgMITRZHNlSaDC1/BzaNq0iLaJCS P5nz99DGlBD9vPg7mw8ebM+QLypkR/N7KGf3/ubcOD7KnPzNlqESiSGEYNeLSAgZRYnts4mb8 +9syYuL0Px4j/1Bs7hMQ== X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220826_015031_531221_E4BDEAD7 X-CRM114-Status: GOOD ( 21.97 ) 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 Fri, Aug 26, 2022 at 1:15 AM Eric Biggers wrote: > > 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. 7206dc93a58f ("arm64: Expose Arm v8.4 features") added the feature bit for Armv8.4+ processors. From what I can tell from the documentation and the kernel source, I see: - if the feature is set in HWCAP (or /proc/cpuinfo), then the instruction DIT register is available in user space, and sensitive code can set or clear the constant-time mode for the local thread. - On CPUs without the feature (almost all ARMv8 ones), the register should not be touched. - The bit is context switched on kernel entry, so setting the bit in user space does not change the behavior inside of a syscall - If we add a user space interface for setting the bit per thread on x86, the same interface could be supported to set the bit on arm64 to save user space implementations the trouble of checking the feature bits - the in-kernel crypto code does not set the bit today but could be easily changed to do this for CPUs that support it, if we can decide on a policy for when to enable or disable it. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel