linux-kernel - Re: Should Linux set the new constant-time mode CPU flags?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Ywh09ZXBZFA3R0W6@worktop.programming.kicks-ass.net>
Date:   Fri, 26 Aug 2022 09:23:33 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     x86@...nel.org, linux-arm-kernel@...ts.infradead.org,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
        Adam Langley <agl@...gle.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Ard Biesheuvel <ardb@...nel.org>
Subject: Re: Should Linux set the new constant-time mode CPU flags?

On Thu, Aug 25, 2022 at 11:15:58PM +0000, Eric Biggers wrote:
> 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.)

Whichever way around I think you want OS support to make it a per-task
property instead of a per CPU one.

Also, *sigh* yet another MSR to touch :/