[FEAT] Additional Kernel Boot Parameters

[raja-grewal]

Benefit

I was browsing through the current kernel boot parameters and potentially noticed a few ones that we could consider maybe adding to the config. From those below, some could certainly be optional while others might be candidates for enabling by default after comprehensive testing.

Solution

Candidates for inclusion by default are: kfence.sample_interval=100, vdso32=0, cfi=kcfi, efi_pstore.pstore_disable=1, erst_disable. Candidates for optional inclusion are: ipv6.disable=1.

Alternatives

Retain current kernel boot parameters without modification.

Declaration

• I agree to follow this project's Code of Conduct.
• I declare that this is not a request for alternate community messaging or social platforms.
• I declare that I have read the secureblue website and my feature request is in-scope.

[alexvojproc]

What's the rationale for each? Particularly ipv6.disable=1

[raja-grewal]

To provide more detail than the above see the below.

Candidates for inclusion by default are:

• kfence.sample_interval=100: Enable the kernel "Electric-Fence" sampling-based memory safety error to detect heap out-of-bounds access, use-after-free, and invalid-free errors.
• vdso32=0: Disable 32-bit Virtual Dynamic Shared Object (vDSO) mappings as these are a legacy compatibility feature for superseded glibc versions.
• cfi=kcfi: Switch (back) to using kCFI as the default Control Flow Integrity (CFI) implementation as kCFI mandates hash validation at the source making it more difficult to bypass. This is in contrast to FineIBT which was made the default in kernel 6.2 and may result in some performance benefits as it only performs hash checks at the destinations.
• efi_pstore.pstore_disable=1 and erst_disable: Disable both the EFI persistent storage feature and Error Record Serialization Table (ERST) support as a form of defense-in-depth. This prevents the kernel from writing crash logs and other persistent data to the storage backend.

Candidates for optional inclusion are:

• ipv6.disable=1: Disable the entire IPv6 stack functionality.

Obviously this is just a guide to open up a discussion and nothing is being concretely requested.

As some form of evidence for their validity and functionality, they are all but the last one enabled by default in Kicksecure/Whonix config. Though it should be noted that all these have not been tested as the upcoming Debian 13 (kernel 6.12) port is yet to be released, hence only those available on Debian 12 (kernel 6.1) have been tested. The ones not tested live are cfi=kcfi and ipv6.disable=1.

In order to keep this issue brief, please refer to the linked Kicksecure configs where you can find further details and references regarding each parameter.

I look forward to any feedback!

[RoyalOughtness]

@raja-grewal Thanks for the suggestions

kfence.sample_interval=100

Already set by default for fedora's kernel.

vdso32=0

Not set by default for fedora's kernel, seems reasonable to add.

cfi=kcfi

This was discussed at some length in our discord already. There are pros and cons of each approach and given that there isn't a clear advantage either way, we opted to defer to the kernel

efi_pstore.pstore_disable=1

Already set by default for fedora's kernel

erst_disable

Strangely, I see no record of ERST being initialized in dmesg logs on secureblue. 🤔

ipv6.disable=1

see #1078, we have no interest in discriminating against IPv6 😅

[raja-grewal]

@alexvojproc @RoyalOughtness

Thanks for the feedback and review.

Regarding ci=kcfi in particular, could you please point me roughly where and what was discussed regarding the the pros and cons. I respect your decision to opt with the new kernel default as of version 6.2 and would really appreciate for my own knowledge what went into this choice.

Personally, to me it seems clear that for security purposes reverting back to the previous default of cfi=kcfi is a good idea and so would genuinely appreciate to hear some counterarguments to find out if I have made a mistake.

When it comes to ipv6.disable=1 I was not suggesting to disable it be default, only perhaps consider providing the option as you do with ia32_emulation=0 as a form of attack surface reduction for interested individuals.

[RoyalOughtness]

@raja-grewal While putting together sources from the discussion we had last year, I found this article from this year that's pretty damning for FineIBT:

https://www.phoronix.com/news/Linux-FineIBT-Critically-Flawed

Given this, it seems reasonable to set cfi=kcfi

[RoyalOughtness]

@raja-grewal However, if they did merge the change to require FRED for FineIBT, then the whole conversation is moot because no intel cpus have support for FRED yet. Let me check.

[RoyalOughtness]

@raja-grewal have a look here

torvalds/linux@97e5967#diff-69a1bc4a724617e303dd8cba2395d68b06a977953dea7c9c2ff919fbeaf1d93cR1145

They added a new "paranoid" mode for FINEIBT that is the default in the absence of intel FRED:

The fineibt_paranoid caller sequence adds additional caller side
hash validation. This stops such circumvention attacks dead, but at the cost
of adding a load.

[RoyalOughtness]

When it comes to ipv6.disable=1 I was not suggesting to disable it be default, only perhaps consider providing the option as you do with ia32_emulation=0 as a form of attack surface reduction for interested individuals.

I'm fine adding it in this way

[raja-grewal]

Thanks for providing that kernel reference, I was not at all aware of it especially since it only was recently committed on 26 Feb 2025.

Inspecting the C code, it appears that this default is only applied if a CPU does not have the prerequisite X86_FEATURE_FRED feature bit to indicate FRED support. I am not an expert on how these feature bits are managed or even if it is possible for them to be manipulated by a sophisticated adversary.

Therefore, I still think it would be more prudent to revert back to using cfi=kcfi as that way we do not have to be totally reliant on the proper functioning of an additional parameter whose management is outside of the scope of secureblue. If we go back to cfi=kcfi which was the default prior to kernel 6.2, we at least have substantially more confidence that it will work as specified given it was globally used for a long time and so has likely been far more thoroughly audited over the years.

[HastD]

I'm now running my system (kinoite-main-hardened image) with the kernel arguments cfi=kcfi, vdso32=0, and erst_disable in addition to the ones currently set by ujust set-kargs-hardening (including the "unstable" ones and ia32_emulation=0, but not including nosmt=force), and everything seems to be working as before—no immediately apparent issues.

[RoyalOughtness]

X86_FEATURE_FRED feature bit to indicate FRED support. I am not an expert on how these feature bits are managed or even if it is possible for them to be manipulated by a sophisticated adversary.

Intel FRED hasn't shipped on any CPUs yet afaik. It's coming with new CPUs later this fiscal year.

Therefore, I still think it would be more prudent to revert back to using cfi=kcfi as that way we do not have to be totally reliant on the proper functioning of an additional parameter whose management is outside of the scope of secureblue. If we go back to cfi=kcfi which was the default prior to kernel 6.2, we at least have substantially more confidence that it will work as specified given it was globally used for a long time and so has likely been far more thoroughly audited over the years.

I'm not convinced by this. kcfi is already used if fineibt isn't applicable. If fineibt is applicable, a software mitigation (paranoid mode) is applied in the absence of a hardware mitigation (Intel FRED). If Intel FRED is available, then the software mitigation is not needed.

So, it seems like the kernel has this taken care of 🙂

[RoyalOughtness]

so has likely been far more thoroughly audited over the years.

I believe FineIBT still uses kcfi instrumentation for the software extensions: https://lpc.events/event/16/contributions/1315/attachments/1067/2169/cfi.pdf

More generally though, our policy is to not change any kernel parameters unless there's a quantifiable security advantage to doing so. Then, we can track changes to that quantifiable advantage over time, which gives us objective criteria with which to determine that we should undo our karg setting.

Without this, there are far too many ways we could end up shooting ourselves in the foot. The kernel is constantly changing, and without a way to measure those changes against our decisions, we could end up missing improvements that render our decisions obsolete or worse, a security degradation relative to the default. The recent addition of paranoid mode for FineIBT is a great example of this, in that FineIBT will likely continue to improve, and so at what point would we decide to undo cfi=kcfi? What's are the criteria? What's the quantifiable advantage of kcfi?

[RoyalOughtness]

Also @raja-grewal, as @RKNF404 just pointed out on discord, this conversation is somewhat moot since kcfi is only available if the kernel is built with clang. Fedora's is not, and I believe debian's also is not. @raja-grewal is kicksecure building your own kernel with clang? If not, then this conversation is probably moot.

However, this may change with: https://lwn.net/Articles/1035117/