From: Dave Hansen <dave.hansen@intel.com>
To: Demi Marie Obenour <demiobenour@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Eric Biggers <ebiggers@kernel.org>,
Andrew Cooper <andrew.cooper3@citrix.com>
Cc: x86@kernel.org, Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: Turning on DOITM at last
Date: Mon, 20 Jul 2026 04:55:19 -0700 [thread overview]
Message-ID: <b2986cfd-6e2c-47c8-8a42-863582ebf1fa@intel.com> (raw)
In-Reply-To: <5e739bc7-4252-4f64-90ab-c68fc5cc746c@gmail.com>
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.
next prev parent reply other threads:[~2026-07-20 11:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-18 17:01 Turning on DOITM at last Demi Marie Obenour
2026-07-20 11:55 ` Dave Hansen [this message]
2026-07-20 16:29 ` Eric Biggers
2026-07-20 17:01 ` Andrew Cooper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b2986cfd-6e2c-47c8-8a42-863582ebf1fa@intel.com \
--to=dave.hansen@intel.com \
--cc=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=demiobenour@gmail.com \
--cc=ebiggers@kernel.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.