Turning on DOITM at last

Turning on DOITM at last

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 633 bytes --]

Is it time to go ahead and turn on DOITM?

Here's my reasoning:

- If it doesn't do anything, it's a harmless no-op.

- If it does something, then that something needed to be done to
  protect code that handles secrets, such as crypto code.

- The overhead of switching it on and off is too high, so it's best
  to just leave it on all the time.

- 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.

Xen already turned it on in the past.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Turning on DOITM at last

[Dave Hansen]

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.

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