Ditana provides access to advanced kernel configurations during installation. These settings allow you to optimize your system’s behavior according to your specific requirements. Each option has been carefully selected to provide meaningful improvements for specific use cases.
Default Configuration
Ditana enables certain kernel optimizations by default, carefully balancing performance, security, and usability. Specific defaults include:
Parameters meant to be used to optimize ZRAM (which is enabled in Ditana, but - as everything - you can switch it off)
Memory-related optimizations based on available RAM
Immediate OOM-killing for better system stability
Unprivileged container support enabled
Enhanced device initialization ordering
Memory zeroing on allocation and deallocation
If you prefer to use the kernel’s default settings (which might be more suitable for specific workloads or when maximum compatibility is required), you can uncheck all options during installation.
1 - General Kernel Configuration
Kernel parameters configured to enhance system performance, security, and resource management.
These kernel parameters are configured to optimize system performance, security, and resource management. You may choose to adjust these settings based on your specific requirements.
List of General Kernel Configuration Settings
Enable Magic SysRq Keys
Related kernel setting: kernel.sysrq=0 ⇨ 1
Enables the SysRq (commonly ‘Print Screen’) key for emergency recovery actions, such as Alt+SysRq+B to reboot.
Default: activated
Reduce Background Reclaiming of Filesystem Cache
Related kernel setting: vm.vfs_cache_pressure100 ⇨ 50
Retains more filesystem metadata in memory for faster access, increasing RAM usage.
Default: activated if system as more than 24 GB RAM.
Minimize Background Memory Compaction
Related kernel setting: vm.compaction_proactiveness20/100 ⇨ 1/100
Reduces effort spent on memory compaction in the background, which may decrease CPU load at the cost of increased RAM consumption.
Default: activated if system as more than 24 GB RAM.
Order Device Initialization & Power Tasks
Related kernel setting: fw_devlink ⇨ permissive
Facilitates the correct sequence of device initialization and power management tasks based on firmware information. This ensures stable system operation by prioritizing the initialization of supplier devices before consumers and managing power states effectively during suspend/resume cycles.
Default: activated
Allow Normal Users to Run Unprivileged Containers
Related kernel setting: kernel.unprivileged_userns_clone0 ⇨ 1
This is crucial for running containers, such as Docker, in a more secure manner without granting users full root privileges. For example, a developer can run Docker containers for testing purposes without needing administrative access to the system.
Default: activated
Allow Normal Users to Access Performance Profiling Tools
Related kernel setting: perf_event_paranoid0 ⇨ 1
This is particularly useful for developers who need to analyze application performance in a more secure way without needing full root privileges.
Default: activated
Automatically Fill Allocated Memory with 0
Related kernel setting: init_on_alloc0 ⇨ 1
Increases security by zeroing out newly allocated memory.
Default: activated
Automatically Fill Deallocated Memory with 0
Related kernel setting: init_on_free0 ⇨ 1
Aids in preventing data leakage by clearing freed memory.
Default: activated
2 - ZRAM related kernel configuration
These settings are recommended to optimize ZRAM performance.
ZRAM is enabled by default. In dialog «Storage & File System Options» you may disable it. If you modify kernel settings that would degrade ZRAM’s performance, or the performance of a system without ZRAM (in case ZRAM is disabled), a warning will be displayed when confirming such kernel settings.
List of ZRAM related settings
Optimize swap file and ZRAM usage
Related kernel setting: vm.swappiness
If you have left ZRAM enabled (default), this setting changes the swappiness from the default of 60 to the recommended value of 180. If you have ZRAM disabled, this setting changes swappiness to 1, which conserves RAM for active applications to improve system responsiveness, but leaves less RAM available for kernel operations such as caching file system metadata and managing network buffers. Unchecking the setting will use the kernel default in all cases.
Default: activated if zram is enabled, else if system as more than 24 GB RAM.
Disable Zswap Cache Layer
Related kernel parameter: zswap.enabled=0
Disables Zswap’s intermediary cache, allowing direct use of swap devices like ZRAM.
Default: activated if zram is enabled
Disable Swap Readahead
Related kernel setting: vm.page-cluster3 ⇨ 0
The system reads only one page at a time from swap, potentially reducing initial latency when accessing swapped-out pages. This is advantageous when using ZRAM, as ZRAM provides fast access to swap space. Reading only the required pages can improve performance without the overhead of prefetching additional pages.
Default: activated if zram is enabled
Disable Extra Memory Reclaim
Related kernel setting: vm.watermark_boost_factor15000 ⇨ 0
This reduces reclaim activity during memory fragmentation when high-order memory allocations are less critical. This can optimize memory management for systems using ZRAM. Since ZRAM reduces the need for high-order memory allocations, the extra memory reclaim becomes unnecessary, improving overall performance.
Default: activated if zram is enabled
Maintain free memory
Related kernel setting: vm.watermark_scale_factor 10/3000 ⇨ 125/3000
Make the Kernel Swap Thread more aggressive in maintaining free memory. This helps prevent applications from entering direct memory reclaim, enhancing system responsiveness under memory pressure. This is particularly beneficial for systems with ZRAM, because it allows the system to better utilize ZRAM’s fast swap capabilities by maintaining more free memory and reducing allocation stalls.
Default: activated if zram is enabled
3 - CPU Vulnerability Mitigation Options
Instead of anticipating it, let the user decide if to make compromises regarding CPU vulnerabilities.
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.
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.
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:
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.
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.
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.
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.
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).
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.
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.
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.