CPU Vulnerability Mitigation Options
CPU Vulnerability Mitigation Configuration
In line with Ditana’s design philosophy, our distribution enables CPU vulnerability mitigations in High Security Mode by default. During installation, Ditana’s installer allows you to manage each detected CPU vulnerability individually, offering the option to maintain these enhanced security settings or revert to the default kernel configurations.
Default Kernel Settings vs. Ditana’s Mitigations
The default kernel settings provided by the Linux kernel developers strive to balance security and performance. However, these settings do introduce certain security vulnerabilities. Ditana prioritizes robust security by enabling mitigations that address these vulnerabilities without significantly impacting system performance. For most users, the performance implications of Ditana’s mitigations are negligible, while the security benefits are substantial.
Customization and Flexibility
We understand that some users may prefer to optimize their systems for maximum performance, even if it means accepting potential security trade-offs. To accommodate this, Ditana’s installer framework empowers you to adjust CPU vulnerability mitigation settings according to your preferences. Comprehensive explanations for each mitigation option are available through the installer’s Help button and detailed below.
Hardware-Specific Configuration
Please note that the application of these kernel settings is tailored to your specific hardware configuration. Ditana’s hardware detection system ensures that mitigation settings are applied appropriately based on the vulnerabilities relevant to your CPU model.
By choosing to adhere to Ditana’s default mitigation settings, you ensure that your system maintains a high level of security against known CPU vulnerabilities. We recommend keeping these settings enabled to protect your system, unless you have specific needs that justify adjusting them for performance gains.
Additional sources beyond kernel.org
Various microprocessor flaws have been discovered recently. Certain issues require SMT be disabled in order to more fully mitigate the issue.
Both TU Graz and VUSec recommend that software makers disable hyperthreading, a feature of Intel chips that accelerates their processing by allowing more tasks to be performed in parallel, but could make certain variants of the MDS attacks vastly easier to pull off.
In 2019 a set of vulnerabilities led to security experts recommending the disabling of hyper-threading on all devices.
After Installation
Mitigations often include disabling Hyperthreading (SMT) as a fallback. Upon installation, Ditana’s custom terminal header output will display the active mitigations. Note that only enabled mitigations are shown, while any that remain disabled are simply omitted to keep the output concise. Moreover, the output contains information if Hyperthreading (SMT) is enabled or not.
In addition, you can verify applied mitigations by running:
lscpu
To compare performance with and without mitigations, reboot, press e at the boot menu (GRUB), and edit the boot parameters. Remove the parameter associated with a specific mitigation for testing. The specific parameters for each mitigation can be found in the list below under “Applied mitigation.” Reboot and run your usual tasks to evaluate any performance impact rather than using synthetic benchmarks.
If you decide to disable a mitigation permanently, open /etc/default/grub in a terminal editor:
micro /etc/default/grub
Locate the GRUB_CMDLINE_LINUX_DEFAULT line, take a photo of it as a backup, and remove the desired parameters as you did before. Save with Ctrl+S (you will be asked for your password), then run:
sudo grub-mkconfig -o /boot/grub/grub.cfg
After reboot, these settings will persist. If an error prevents booting, use the GRUB boot menu to correct the parameters, then repeat these steps to apply the fix.
Disclaimer
The guidance here relies on the official CPU vulnerability documentation and kernel command-line parameter documentation. Different Ditana-supported kernels may exhibit variations from kernel.org defaults, with occasional complex side effects. Our testing shows these parameters to be effective across kernel versions. We invite you to submit a GitHub issue or join us on Discord to discuss any topic, including kernel parameterization.
In our experience, as developers often working with 100% CPU loads, setting “High Security” across all tested hardware has shown minimal performance impact, even with hyperthreading disabled. This may not apply to all workloads. If your activities benefit from adjusting Ditana’s defaults, please let us know; we aim to refine the installation wizard to accommodate specific hardware needs.
Ditana’s handling of the specific CPU vulnerabilities
Spectre Variant 2 (Branch Target Injection)
This vulnerability allows attackers to exploit speculative execution to access sensitive data. Enabling this option forces the kernel to apply full mitigations for Spectre Variant 2, potentially enhancing security.
For example, on a 12th Gen Intel(R) Core(TM) i9-12900T CPU (which is affected), running lscpu without this mitigation enabled shows:
Spectre v2: Mitigation; Enhanced / Automatic IBRS; IBPB conditional; RSB filling; PBRSB-eIBRS SW sequence; BHI BHI_DIS_S
With this mitigation enabled, lscpu reports:
Spectre v2: Mitigation; Enhanced / Automatic IBRS; IBPB always-on; RSB filling; PBRSB-eIBRS SW sequence; BHI BHI_DIS_S
On this specific CPU, the difference is that the Indirect Branch Prediction Barrier (IBPB) is applied consistently (always-on), rather than conditionally. For this CPU model, Hyper-Threading (SMT) remains enabled.
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.
Identifier used to detect via lscpu |
Spectre v2 |
| Name of the mitigation in the settings | Enforce Spectre Variant 2 Mitigation |
| Applied mitigation | spectre_v2=on |
L1 Terminal Fault (L1TF)
Affects Intel CPUs, allowing unauthorized access to data in the Level 1 cache. This option enforces full mitigation, which may involve more 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.
Identifier used to detect via lscpu |
L1tf |
| Name of the mitigation in the settings | Enforce L1 Terminal Fault Mitigation |
| Applied mitigation | l1tf=full,force |
Microarchitectural Data Sampling (MDS)
Allows attackers to sample data from CPU buffers. Enabling this enforces full mitigations and may disable Simultaneous Multithreading (SMT) if necessary.
The kernel does not by default enforce the disabling of SMT, which leaves SMT systems vulnerable when running untrusted code. The same rationale as for L1TF applies.
Identifier used to detect via lscpu |
Mds |
| Name of the mitigation in the settings | Enforce MDS Mitigation |
| Applied mitigation | mds=full,nosmt |
TSX Asynchronous Abort (TAA)
Affects CPUs with Transactional Synchronization Extensions (TSX). This option enables full mitigation and may disable SMT if required.
TSX might be disabled if microcode provides a TSX control MSR. If so, system is not vulnerable.
Identifier used to detect via lscpu |
Tsx async abort |
| Name of the mitigation in the settings | Enforce TSX Async Abort Mitigation |
| Applied mitigation | tsx_async_abort=full,nosmt |
Meltdown (L1D Flushing)
Exploits speculative execution to read kernel memory. Enabling this forces the kernel to flush the Level 1 data cache to mitigate Meltdown.
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.
Identifier used to detect via lscpu |
Meltdown |
| Name of the mitigation in the settings | Enforce Meltdown Mitigation |
| Applied mitigation | l1d_flush=on |
MMIO Stale Data Vulnerabilities
Allows leakage of data from Memory-Mapped I/O. This enforces full mitigations and may disable SMT if needed.
full,nosmt- Same asfull, with SMT disabled on vulnerable CPUs. This is the complete mitigation.
Identifier used to detect via lscpu |
Mmio stale data |
| Name of the mitigation in the settings | Enforce MMIO Stale Data Mitigation |
| Applied mitigation | mmio_stale_data=full,nosmt |
Retbleed (Cross-Thread Return Address Predictions)
A speculative execution attack that can leak return addresses. This option enables automatic mitigation and may disable SMT.
auto,nosmt - automatically select a mitigation, disabling SMT if necessary for the full mitigation
Identifier used to detect via lscpu |
Retbleed |
| Name of the mitigation in the settings | Enforce Retbleed Mitigation |
| Applied mitigation | retbleed=auto,nosmt |
See Cross-Thread Return Address Predictions for the details on kernel.org.
Speculative Return Stack Overflow (SRSO)
Leads to speculative execution attacks via the return stack buffer. Enabling this applies mitigations and may impact performance.
‘Note that User->User mitigation is controlled by how the IBPB aspect in the Spectre v2 mitigation is selected: […] strict: i.e., always on - by supplying spectre_v2_user=on on the kernel command line […] ‘Mitigation: IBPB’: Similar protection as “safe RET” above but employs an IBPB barrier on privilege domain crossings (User->Kernel, Guest->Host).
Identifier used to detect via lscpu |
Spec rstack overflow |
| Name of the mitigation in the settings | Enforce SRSO Mitigation |
| Applied mitigation | spec_rstack_overflow=ibpb spectre_v2_user=on |
Gather Data Sampling (GDS)
Affects AVX instructions. This option forces microcode mitigations or disables AVX if the microcode is unavailable.
Specifying “gather_data_sampling=force” will use the microcode mitigation when available or disable AVX on affected systems where the microcode hasn’t been updated to include the mitigation.
Identifier used to detect via lscpu |
Gather data sampling |
| Name of the mitigation in the settings | Enforce Gather Data Sampling Mitigation |
| Applied mitigation | gather_data_sampling=force |
Register File Data Sampling (RFDS)
Allows sampling of data from CPU registers. Enabling this activates mitigations to protect against RFDS.
This parameter overrides the compile time default set by CONFIG_MITIGATION_RFDS.
Identifier used to detect via lscpu |
Reg file data sampling |
| Name of the mitigation in the settings | Enforce RFDS Mitigation |
| Applied mitigation | reg_file_data_sampling=on |
See Register File Data Sampling (RFDS) for the details on kernel.org.
Not included CPU vulnerabilities
These vulnerabilities are not included in the Ditana installer, because the kernel performs maximum mitigation by default.
Spectre Side Channels: variant 1 (Bounds Check Bypass)
there is no guarantee that all possible attack vectors for Spectre variant 1 are covered.
Identifier used to detect via lscpu |
Spectre v1 |
iTLB multihit
Identifier used to detect via lscpu |
Itlb multihit |
See iTLB multihit for the details on kernel.org.
SRBDS - Special Register Buffer Data Sampling
Identifier used to detect via lscpu |
Srbds |
See SRBDS - Special Register Buffer Data Sampling for the details on kernel.org.
Speculative Store Bypass (SSB)
The kernel provides mitigation for such vulnerabilities in various forms.
Identifier used to detect via lscpu |
Spec store bypass |
Mitigation Reduction Options
In addition to the specific CPU vulnerability mitigations, Ditana provides options to reduce or disable mitigations globally. Please note that using these options can significantly increase the security risks associated with your system.
Disable Intel BTI Mitigation - Security Risk! Undocumented! (ibt=off)
This option disables the Intel Branch Target Injection (BTI) mitigation. Warning: This is an undocumented kernel parameter and is generally not recommended. Despite its widespread use and often being set as a default without explicit communication, disabling BTI can expose the system to security vulnerabilities.
The primary purpose of BTI mitigation is to protect against certain speculative execution attacks by enforcing Control-flow Enforcement Technology (CET) Shadow Stack. More details can be found in the CET Shadow Stack documentation.
Usage Warning: Disabling BTI mitigation may expose your system to potential security threats. It is advised to keep this mitigation enabled unless you have a specific, justified need to disable it.
Disable All Mitigations - Security Risk! (mitigations=off)
This option differs from disabling all mitigations that Ditana offers, because it disables all mitigations that the kernel offers. Warning: Disabling all mitigations poses a high security risk and is strongly discouraged unless absolutely necessary for specific use cases.
By setting mitigations=off, the system will not apply any of the available mitigations for known CPU vulnerabilities, potentially exposing the system to various speculative execution and side-channel attacks.
For more information, refer to the Kernel Parameters Documentation.
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.