TODO: Need to check if secureblue has hardening settings that we lack that would be applicable here too.
Thank you! Merged.
Update on CPU mitigations.
One area of discussion is the inclusion of gather_data_sampling=force which will disable AVX if the system does not have a suitable microcode update.
Given that we are already disabling SMT, also disabling AVX may potentially cripple older processors if the instruction set is utilised by users.
The exact performance implications of this parameter on older EOL CPUs depends on workloads but I personally do not have any suitable physical hardware to test this myself.
Similarly the impact of VMs may also be significant for the same reasons.
Minor update to README.md and updated copyright since we are now in May 2024.
Very interesting article that basically reinforces what was written in authoritative guides years ago.
The key takeaway is again that “[i]n the kernel, just about any bug, if you’re clever enough, can be exploitable to compromise the system.”
Their recommendation to use only stable releases is something I would agree being the optimal longer term strategy.
However, this would likely bring major QA costs since constantly upgrading the kernel can has the strong potential to cause breakages (something any user of a rolling release distribution would be familiar with over the years).
Regardless, we are obviously highly vulnerable to this attack surface since we are reliant on Debian though in my opinion I currently see no superior alternative at this stage.
In terms of the super long-term future, switching to a image-based (‘immutable’) distribution would probably be advantageous given the myriad of security benefits. One benefit would be to mimic modern Android’s support for read-only file systems (when it comes to critical directories). Another valued feature would be the ability to provide attestation support to verify the authenticity of the distributions ‘image’ to ensure it has not been tampered.
I wonder how much secure (or less secure) BSD OS’s are…
I suspect any kernel written in a language where memory is managed manually is going to be more susceptible to terrifying exploits. Wonder long term possibility of Rust based OS’s…
Dont have much useful to add…just thoughts
If packages.debian.org, kernel.org or another trustworthy source would provide a Debian stable compatible APT repository with stable Linux kernels, that might be an option.
Otherwise this unfortunately is not actionable. Kernel re-compilation (with or without changed (security) settings) is too difficult and maintenance intensive given the current project resources.
Usability / reliability issues are also a risk.
related: