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
| ||
|
Date: Mon, 29 Aug 2022 15:09:30 -0400 From: "Jason A. Donenfeld" <Jason@...c4.com> 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>, Ard Biesheuvel <ardb@...nel.org> Subject: Re: Should Linux set the new constant-time mode CPU flags? On Mon, Aug 29, 2022 at 06:08:07PM +0000, Eric Biggers wrote: > 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. Right. It's actually kind of surprising that Intel didn't already do this by default. Sure, maybe the Intel manual never explicitly guaranteed constant time, but a heck of a lot of code relies on that being the case. Jason
Powered by blists - more mailing lists