Should all kernel patches for CPU bugs be unconditionally enabled? Vs Performance vs Applicability

This is an important point. I was wondering about this too. And I could be wrong here. It would be very much desirable to simplify this. However, I think mitigations=auto isn’t the same as mitigations=force, while the latter does not seem to exist yet. This seems like a missing kernel feature but I wasn’t sure it’s worth a feature request.

mitigations=auto means “conditionally enable” while mitigations=force would mean “unconditionally enable”.

https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/index.html and following pages don’t mention mitigations=.

quote https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html?highlight=kernel%20parameters

[X86,PPC,S390,ARM64] Control optional mitigations for
CPU vulnerabilities. This is a set of curated,
arch-independent options, each of which is an
aggregation of existing arch-specific options.

auto (default)

I.e. auto is already the default. mitigations=auto would essentially do nothing.

Mitigate all CPU vulnerabilities, disabling SMT
if needed. This is for users who always want to
be fully mitigated, even if it means losing SMT.
Equivalent to: l1tf=flush,nosmt [X86]
mds=full,nosmt [X86]
tsx_async_abort=full,nosmt [X86]

It does not set l1tf=full,force, nosmt=force, tsx=off, spectre_v2=on, pti=on.

https://docs.clip-os.org/clipos/kernel.html writes

  • mitigations : This parameter controls optional mitigations for CPU vulnerabilities in an arch-independent and more coarse-grained way. For now, we keep using arch-specific options for the sake of explicitness. Not setting this parameter equals setting it to auto , which itself does not update anything.
1 Like

I don’t see any point in forcing these to be enabled. The kernel will automatically detect if the CPU is vulnerable and if it is, will enable the mitigations. If it isn’t vulnerable, it won’t enable the mitigations but that doesn’t matter since they aren’t needed.

Debian disables TSX by default with CONFIG_X86_INTEL_TSX_MODE_OFF=y but I guess the tsx=off parameter is useful for kernels with it enabled by default.

nosmt=force is redundant. We already disable SMT with mds=full,nosmt.

tsx_async_abort=full,nosmt is redundant as TSX is already disabled.


Which ones? All recent ones or only the ones mentioned in your last post?


mds=full,nosmt does not make that redundant.
Though, l1tf=full,force makes it redundant.

l1tf=full,force https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt says

Implies the ‘nosmt=force’ command line option. (i.e. sysfs control of SMT is disabled.)

mds=full,nosmt does not say “Implies the ‘nosmt=force’”.

The reason why I am interested in nosmt=force is:

Force disable SMT, cannot be undone via the sysfs control file.

Which seems useful at least for purposes of Untrusted Root - improve Security by Restricting Root.

I see your point. But I am not sure.

As per https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/tsx_async_abort.html here are some possible combinations (these are listed in a table on that page):

  • tsx=on
  • tsx_async_abort=full,nosmt
  • As above, cross-thread attacks on SMT mitigated.

  • tsx=off
  • tsx_async_abort=full,nosmt
  • TSX might be disabled if microcode provides a TSX control MSR. If so, system is not vulnerable.

What also confuses me:

Default mitigations

The kernel’s default action for vulnerable processors is:

Deploy TSX disable mitigation (tsx_async_abort=full tsx=off).

A combination of tsx=off and tsx_async_abort=full.

Why didn’t they write simpler:

Deploy TSX disable mitigation (tsx=off).

Therefore perhaps better to keep tsx_async_abort=full,nosmt?

1 Like

3 posts were merged into an existing topic: Whonix vulerable due to missing processor microcode packages? spectre / meltdown / retpoline / L1 Terminal Fault (L1TF)

All except maybe tsx=off.


full,nosmt - Enable MDS mitigation and disable SMT on vulnerable CPUs


nosmt=force: Force disable SMT, cannot be undone via the sysfs control file.

They both do essentially the same thing. mds=full,nosmt can’t be undone via sysfs either.

user@host:~$ cat /sys/devices/system/cpu/smt/control

My interpretation of the docs is using tsx=off and tsx_async_abort=full,nosmt together will only disable TSX if the mitigation isn’t available. Just using tsx=off should disable TSX regardless.

1 Like

I might still misinterpret that. Please send a pull request since I guess that is easier than trying to ask/explain it.

Intuition tells me that

  • if tsx=off is set, i.e. if tsx is disabled anyhow, there is no need for tsx_async_abort=full.
  • but on the other hand if tsx=off is set anyhow, tsx_async_abort=full is superfluous and shouldn’t do harm. Therefore in doubt, set it.

However, quote https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/tsx_async_abort.html contradicts my intuition:

Default mitigations
The kernel’s default action for vulnerable processors is:
Deploy TSX disable mitigation (tsx_async_abort=full tsx=off).

Therefore I interpret tsx_async_abort=full tsx=off as a valid, sensible, non-illogical option. Switching tsx_async_abort=full to tsx_async_abort=full,nosmt is just an extension of that.

The kernel’s default action for vulnerable processors is tsx_async_abort=full tsx=off. Therefore I concluded to set tsx_async_abort=full tsx=off regardless to reach goal of unconditionally enabling mitigation seven if the processor not detected as vulnerable. [Plus add ,nosmt.]

I guess we’ll get only higher certainty on that by asking the kernel developers and/or reading the kernel source code.

1 Like


My interpretation of the docs is using tsx=off and tsx_async_abort=full,nosmt together will only disable TSX if the mitigation isn’t available . Just using tsx=off should disable TSX regardless.

Using tsx_async_abort=full along with tsx=off will still enable TSX which can leave us open to 0days the mitigation doesn’t prevent.

Just using tsx=off should leave TSX always disabled and protect us from all TSX vulnerabilities.

1 Like

Could you please look this up in the kernel source code?

1 Like

I couldn’t find anything.

I think we should just leave all CPU mitigation things to the kernel default as it automatically enables needed mitigations if the device is vulnerable.

Is this a complete reversal of your original post here Should all kernel patches for CPU bugs be unconditionally enabled? Vs Performance vs Applicability?

1 Like

The original post was more of a question than a suggestion, but yes.


I see. Well these questions / this discussion actually convinced me that this is a good idea. I did re-read this whole forum thread just now. These were the main points which convinced me most:

We’re passing spectre-meltdown-checker --paranoid test.

Then also reading this strengthened this:

Quoting specifically:

Kroah-Hartman dispelled the idea that an issue like Spectre has a single fix. “We are still fixing Spectre 1.0 issues [almost] two years later. It’s taken a couple of thousand patches over [almost] two years. Always take the latest kernel and always take the latest BIOS update.”

There are way too many CPU models and this is a huge mess. I don’t think we have enough people who have each CPU and then test if these vulnerabilities are properly detected and mitigated? Looking at how few care about spectre-meltdown-checker (you’d expect more contributions there), I don’t think there is a strong handle on this issue yet.

We want the High security mode.

Edit by Patrick:
fix typo - propeller -> properly

1 Like

This is a great point. I didn’t think about that. Considering that, forcing mitigations sounds like a really good idea.

1 Like

madaidan via Whonix Forum:




I can confirm with spectre-meltdown-checker set on paranoid, that in addition to the kernel patches and updates to microcode, that for Intel in particular, it is a prudent choice to turn off hyperthreading (depending on what you are doing like workloads and things like that). A lot of the bugs will be mitigated by running the tool in regular mode, but to be doubly sure, turn off smt (in Intel; AMD appears to not have this problem). For example, true mitigation for speculative store bypass can only be had by turning off smt/hyperthreads. There are software solutions via kernel commandline, or you can permanently switch off the capability in uefi settings.


AMD is still affected although not to the extent of Intel. I’d still recommend to disable SMT on AMD too to be sure.


Speak of the devil…

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]