Kernel Hardening - security-misc

This was merged.

1 Like

How about Speculative Return Stack Overflow (SRSO) — The Linux Kernel documentation?


			[X86] Control RAS overflow mitigation on AMD Zen CPUs

			off		- Disable mitigation
			microcode	- Enable microcode mitigation only
			safe-ret	- Enable sw-only safe RET mitigation (default)
			ibpb		- Enable mitigation by issuing IBPB on
					  kernel entry
			ibpb-vmexit	- Issue IBPB only on VMEXIT
					  (cloud-specific mitigation)

See also:

cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow
1 Like

TODO: Need to check if secureblue has hardening settings that we lack that would be applicable here too.

1 Like
1 Like

Thank you! Merged.

1 Like
1 Like

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.

1 Like
1 Like
1 Like
1 Like

Minor update to and updated copyright since we are now in May 2024.

1 Like
1 Like

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.