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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 26 Aug 2022 11:40:25 -0400
From:   Jeffrey Walton <noloader@...il.com>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     X86 ML <x86@...nel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        LKML <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 7:24 PM Eric Biggers <ebiggers@...nel.org> 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.)

The thought that comes to mind for me is, please make setting/clearing
the bit available in userland. Libraries like Botan, Crypto++ and
OpenSSL could benefit from it.

Jeff