CPU vulnerability mitigations
Ditana enables CPU vulnerability mitigations in High Security mode by default. The installer detects which mitigations your specific CPU needs by reading /sys/devices/system/cpu/vulnerabilities/, then offers each as an individually-toggleable checkbox in the Expert Settings → CPU Vulnerability Mitigation Options dialog. This page documents every option in detail.
Default kernel settings vs Ditana’s mitigations
Section titled “Default kernel settings vs Ditana’s mitigations”The upstream Linux defaults balance security against performance and leave certain vulnerabilities unmitigated unless explicitly opted in. Ditana opts in by default — for most workloads the cost is negligible, while the security benefit is substantial. You can revert any individual mitigation in the installer if you have a workload that demonstrably benefits.
The mitigation logic is hardware-specific. Only the vulnerabilities your CPU actually exhibits are configured; everything else is left at the kernel default.
After installation
Section titled “After installation”Several mitigations involve disabling Simultaneous Multi-Threading (SMT, also known as Hyper-Threading) as a fallback. Ditana’s custom terminal header shows which mitigations are active and whether SMT is on or off.
You can also verify with:
lscpuTo compare performance with and without a specific mitigation, reboot, press e at the GRUB menu, and edit the kernel command line — remove the parameter for the mitigation you want to test. The parameters are listed below under “Applied mitigation” for each entry. Reboot and run your real workload (synthetic benchmarks rarely reflect actual impact).
To make a change permanent, edit /etc/default/grub, find the GRUB_CMDLINE_LINUX_DEFAULT line (back it up first), remove the parameter, then run:
sudo grub-mkconfig -o /boot/grub/grub.cfgIf a change prevents booting, edit the kernel command line in the GRUB menu to recover, then repeat the edit and grub-mkconfig.
Mitigations Ditana enables by default
Section titled “Mitigations Ditana enables by default”Spectre variant 2 — Branch Target Injection
Section titled “Spectre variant 2 — Branch Target Injection”Speculative execution exploit allowing attackers to read sensitive data via mistrained indirect branch predictors. Ditana applies the full mitigation (Indirect Branch Prediction Barrier always-on rather than conditional).
All Spectre variant 2 mitigations can be forced on at boot time for all programs. This will add overhead as indirect branch speculations for all programs will be restricted.
lscpu identifier | Spectre v2 |
| Setting name | Enforce Spectre Variant 2 Mitigation |
| Applied parameter | spectre_v2=on |
L1 Terminal Fault (L1TF)
Section titled “L1 Terminal Fault (L1TF)”Affects Intel CPUs, allowing unauthorized access to data in the L1 cache. Ditana enforces full mitigation with aggressive cache flushing.
The kernel does not by default enforce the disabling of SMT, which leaves SMT systems vulnerable when running untrusted guests with EPT enabled.
lscpu identifier | L1tf |
| Setting name | Enforce L1 Terminal Fault Mitigation |
| Applied parameter | l1tf=full,force |
Microarchitectural Data Sampling (MDS)
Section titled “Microarchitectural Data Sampling (MDS)”Allows attackers to sample data from CPU buffers. Full mitigation may disable SMT if necessary.
The kernel does not by default enforce the disabling of SMT, which leaves SMT systems vulnerable when running untrusted code.
lscpu identifier | Mds |
| Setting name | Enforce MDS Mitigation |
| Applied parameter | mds=full,nosmt |
TSX Asynchronous Abort (TAA)
Section titled “TSX Asynchronous Abort (TAA)”Affects CPUs with Transactional Synchronization Extensions. Full mitigation may disable SMT if required.
TSX might be disabled if microcode provides a TSX control MSR. If so, system is not vulnerable.
lscpu identifier | Tsx async abort |
| Setting name | Enforce TSX Async Abort Mitigation |
| Applied parameter | tsx_async_abort=full,nosmt |
Meltdown (L1D flushing)
Section titled “Meltdown (L1D flushing)”Speculative execution exploit allowing kernel memory reads from userspace. Ditana forces L1 data cache flushing.
The kernel command line allows to control the L1D flush mitigations at boot time with the option
l1d_flush=. By default the mechanism is disabled.
lscpu identifier | Meltdown |
| Setting name | Enforce Meltdown Mitigation |
| Applied parameter | l1d_flush=on |
MMIO Stale Data
Section titled “MMIO Stale Data”Data leakage from memory-mapped I/O. Full mitigation may disable SMT.
full,nosmt— Same asfull, with SMT disabled on vulnerable CPUs. This is the complete mitigation.
lscpu identifier | Mmio stale data |
| Setting name | Enforce MMIO Stale Data Mitigation |
| Applied parameter | mmio_stale_data=full,nosmt |
Retbleed — Cross-Thread Return Address Predictions
Section titled “Retbleed — Cross-Thread Return Address Predictions”Speculative execution attack leaking return addresses. Auto-selected mitigation may disable SMT.
auto,nosmt— automatically select a mitigation, disabling SMT if necessary for the full mitigation.
lscpu identifier | Retbleed |
| Setting name | Enforce Retbleed Mitigation |
| Applied parameter | retbleed=auto,nosmt |
See also kernel.org: Cross-Thread Return Address Predictions.
Speculative Return Stack Overflow (SRSO)
Section titled “Speculative Return Stack Overflow (SRSO)”Speculative attacks via the return stack buffer. Combines IBPB barriers with strict spectre_v2-user mode.
‘Mitigation: IBPB’: Similar protection as “safe RET” but employs an IBPB barrier on privilege domain crossings (User→Kernel, Guest→Host).
lscpu identifier | Spec rstack overflow |
| Setting name | Enforce SRSO Mitigation |
| Applied parameter | spec_rstack_overflow=ibpb spectre_v2_user=on |
Gather Data Sampling (GDS)
Section titled “Gather Data Sampling (GDS)”Affects AVX instructions. Forces microcode mitigation, or disables AVX where microcode is unavailable.
Specifying
gather_data_sampling=forcewill use the microcode mitigation when available or disable AVX on affected systems where the microcode hasn’t been updated to include the mitigation.
lscpu identifier | Gather data sampling |
| Setting name | Enforce Gather Data Sampling Mitigation |
| Applied parameter | gather_data_sampling=force |
Register File Data Sampling (RFDS)
Section titled “Register File Data Sampling (RFDS)”Allows sampling of data from CPU registers.
This parameter overrides the compile time default set by
CONFIG_MITIGATION_RFDS.
lscpu identifier | Reg file data sampling |
| Setting name | Enforce RFDS Mitigation |
| Applied parameter | reg_file_data_sampling=on |
See also kernel.org: RFDS.
Vulnerabilities not exposed in the installer
Section titled “Vulnerabilities not exposed in the installer”The kernel performs maximum mitigation by default for these — there is nothing for Ditana to add.
Spectre variant 1 — Bounds Check Bypass
Section titled “Spectre variant 1 — Bounds Check Bypass”There is no guarantee that all possible attack vectors for Spectre variant 1 are covered.
lscpu identifier: Spectre v1
iTLB multihit
Section titled “iTLB multihit”lscpu identifier: Itlb multihit. See kernel.org: iTLB multihit.
SRBDS — Special Register Buffer Data Sampling
Section titled “SRBDS — Special Register Buffer Data Sampling”lscpu identifier: Srbds. See kernel.org: SRBDS.
Speculative Store Bypass (SSB)
Section titled “Speculative Store Bypass (SSB)”The kernel provides mitigation for such vulnerabilities in various forms.
lscpu identifier: Spec store bypass.
Mitigation reduction — at your own risk
Section titled “Mitigation reduction — at your own risk”The installer also exposes two options that reduce mitigations. These significantly increase your exposure to known CPU vulnerabilities. Use only with a clear, justified reason.
Disable Intel BTI mitigation — ibt=off
Section titled “Disable Intel BTI mitigation — ibt=off”Disables Intel Branch Target Injection mitigation. This kernel parameter is undocumented in the official kernel parameters reference, despite being widely set as default on some distributions without explicit communication.
The primary purpose of BTI mitigation is to defend against speculative execution attacks via Control-flow Enforcement Technology (CET) Shadow Stack — see CET Shadow Stack documentation. Disabling it exposes the system to a class of attacks that are otherwise well-defended.
Disable all mitigations — mitigations=off
Section titled “Disable all mitigations — mitigations=off”This is stronger than unchecking every individual mitigation in the dialog. With mitigations=off, the kernel skips every mitigation it knows about — including the ones Ditana doesn’t expose because they’re on by default. The performance ceiling rises; the security floor drops, hard.
Only useful for benchmarks, air-gapped systems with full physical control, or environments where you have categorically other defences.
See kernel.org: kernel parameters.
Disclaimer
Section titled “Disclaimer”The guidance here is based on the official CPU vulnerability documentation and the kernel command-line parameter reference. Different kernel branches occasionally diverge from these defaults in subtle ways; our testing covers the Ditana-supported kernels, but unusual hardware combinations can produce edge cases.
If you have a workload that benefits from a different default, or if you find a CPU model where Ditana’s detection is incomplete or incorrect: please open a GitHub issue or email [email protected]. The detection logic is data, not code — so improvements are usually a few KDL lines.