[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d216cfac-803c-47d2-8fc7-dee3eb346d58@intel.com>
Date: Wed, 20 Aug 2025 09:46:21 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Nikolay Borisov <nik.borisov@...e.com>, x86@...nel.org
Cc: dave.hansen@...ux.intel.comd, linux-kernel@...r.kernel.org, mhocko@...e.de
Subject: Re: [PATCH] x86/tsx: Set default TSX mode to auto
On 8/20/25 06:21, Nikolay Borisov wrote:
> The last known vulnerability concerning TSX was TAA (CVE-2019-11135) a
> lot of time has passed since then and Intel has released a numerous
> processor which do not have the TAA vulnerability (Cooper/Ice Lake,
> Sapphire/Emerald/Granite Rappids) yet have TSX disable by default.
>
> I believe having the default to AUTO rather than OFF strikes a good
> balance between mitigation and reaping the benefits of the TSX feature.
> So let's switch the default to AUTO.
At a bare minimum, the help text needs to get fixed up too. It still says:
Therefore TSX is not enabled by default (aka tsx=off).
I'm also not highly motivated by the fact that CPUs have been released
without TAA. I think TAA is mostly irrelevant. CPUs had been released
with it mitigated even in the original commit that introduced this
Kconfig option: db616173d787 ("x86/tsx: Add config options to set
tsx=on|off|auto").
What has _changed_? Are there lots more folks who want to use TSX than
there were in 2019? Did it get faster? Has the chance of it being
exploited (separate from TAA) gone down?
Now would be the time for folks who are chomping at the bit to use TSX
in their big fancy apps to stand up and say why they want it and why
having their customers use the command-line to override this Kconfig
default is not workable.
Also, from distros, why not just set the Kconfig option to something
other than the default? I mean, we put Kconfig there for a *REASON*.
Let's not pretend that it's a massive engineering effort to change it.
Powered by blists - more mailing lists