lkml.org 
[lkml]   [2022]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2022-08-29 21:10    [W:1.536 / U:0.840 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site