Re: Turning on DOITM at last

Re: Turning on DOITM at last

[Eric Biggers]

[+Cc linux-crypto@vger.kernel.org]

On Mon, Jul 20, 2026 at 04:55:19AM -0700, Dave Hansen wrote:
> On 7/18/26 10:01, Demi Marie Obenour wrote:
> > Is it time to go ahead and turn on DOITM?
> 
> No, I don't think so.
> 
> > - If it doesn't do anything, it's a harmless no-op.
> 
> I kinda disagree with this.
> 
> There are CPUs that enumerate support for DOITM but on which it doesn't
> do anything. On those CPUs, every cycle spent twiddling it is a waste.
> 
> > - If it does something, then that something needed to be done to
> >   protect code that handles secrets, such as crypto code.
> 
> I really disagree with this.
> 
> Lots of code "handles secrets".  memcpy() "handles secrets".
> 
> > - The overhead of switching it on and off is too high, so it's best
> >   to just leave it on all the time.
> 
> The overhead *is* too high. It's an MSR bit that requires a user/kernel
> round trip.
> 
> > - Even people who don't care about speculative execution
> >   vulnerabilities, because they only run trusted code on a particular
> >   server, still likely need secure cryptography.
> 
> I'm not sure where speculative execution vulnerabilities came in to play
> here.
> 
> > Xen already turned it on in the past.
> 
> While I very much respect the Xen folks and their security posture, Xen
> is a very different project than Linux.

The right thing to do for now is to just turn on DOITM at boot time
(https://lore.kernel.org/r/20230125012801.362496-1-ebiggers@kernel.org/)
to fix the backwards compatibility break.  With just one write per CPU
at boot time, the overhead of writing the MSR won't really matter.

For the insecure mode to be the default, there will need to be an
efficient way for userspace to enable the traditional secure mode, *and
then* several years for userspace to be updated.

Unfortunately, since the hardware enabled the insecure mode by default,
Linux inherited that backwards compatibility break without any explicit
patch submission, and the burden is being put on people wanting to
restore the traditional behavior.  It should be the other way around:
the traditional behavior needs to be the default for now, and then we
can discuss what needs to happen for it to be safe to enable the new
insecure mode by default.

- Eric

Re: Turning on DOITM at last

[Andrew Cooper]

On 20/07/2026 5:29 pm, Eric Biggers wrote:
> [+Cc linux-crypto@vger.kernel.org]
>
> On Mon, Jul 20, 2026 at 04:55:19AM -0700, Dave Hansen wrote:
>> On 7/18/26 10:01, Demi Marie Obenour wrote:
>>> Is it time to go ahead and turn on DOITM?
>> No, I don't think so.
>>
>>> - If it doesn't do anything, it's a harmless no-op.
>> I kinda disagree with this.
>>
>> There are CPUs that enumerate support for DOITM but on which it doesn't
>> do anything. On those CPUs, every cycle spent twiddling it is a waste.
>>
>>> - If it does something, then that something needed to be done to
>>>   protect code that handles secrets, such as crypto code.
>> I really disagree with this.
>>
>> Lots of code "handles secrets".  memcpy() "handles secrets".
>>
>>> - The overhead of switching it on and off is too high, so it's best
>>>   to just leave it on all the time.
>> The overhead *is* too high. It's an MSR bit that requires a user/kernel
>> round trip.
>>
>>> - Even people who don't care about speculative execution
>>>   vulnerabilities, because they only run trusted code on a particular
>>>   server, still likely need secure cryptography.
>> I'm not sure where speculative execution vulnerabilities came in to play
>> here.
>>
>>> Xen already turned it on in the past.
>> While I very much respect the Xen folks and their security posture, Xen
>> is a very different project than Linux.
> The right thing to do for now is to just turn on DOITM at boot time
> (https://lore.kernel.org/r/20230125012801.362496-1-ebiggers@kernel.org/)
> to fix the backwards compatibility break.  With just one write per CPU
> at boot time, the overhead of writing the MSR won't really matter.

This is what Xen does, for the same reasons as you've given.

We don't even virtualise the controls for guests.

> For the insecure mode to be the default, there will need to be an
> efficient way for userspace to enable the traditional secure mode, *and
> then* several years for userspace to be updated.
>
> Unfortunately, since the hardware enabled the insecure mode by default,
> Linux inherited that backwards compatibility break without any explicit
> patch submission, and the burden is being put on people wanting to
> restore the traditional behavior.  It should be the other way around:
> the traditional behavior needs to be the default for now, and then we
> can discuss what needs to happen for it to be safe to enable the new
> insecure mode by default.

+1.

It's not just in Linux, it's all OSes and all userspace doing any form
of sensitive operations.

Insecure by default may have been a deliberate choice on Intel's behalf,
but it really is unacceptable for the wider software ecosystem.

~Andrew