Upgrade sysctl settings and docs on kernel panics

[raja-grewal]

This draft pull request replaces now redundant sysctl settings with their newer, equivalent, and more general counterparts when on Linux kernel >= 6.2.

This continues full compliance with KSPP recommendations.

It also splits the forced immediate reboot on a single kernel panic sysctl setting to its own section for clarity. However, the setting remains disabled by default despite this being non-compliant with KSPP recommendations.

Note:
Should ONLY be considered after upgrading to Debian 13 (trixie). Changes have been submitted early to facilitate quicker feedback and review which would ideally enable more swift merging.

Changes

Redundant sysctl settings are removed: kernel.panic_on_oops=1 and kernel.panic_on_warn=1

Upgraded sysctl settings are enabled: kernel.oops_limit=1 and kernel.warn_limit=1

These (draft) changes have also been appropriately updated in debug-misc.

Mandatory Checklist

• Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements:

Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint

Optional Checklist

The following items are optional but might be requested in certain cases.

• I have tested it locally
• I have reviewed and updated any documentation if relevant
• I am providing new code and test(s) for it

[raja-grewal]

See Kicksecure/debug-misc#4 for appropriate updates to debug-misc that continue allowing the disabling functionality.

[ArrayBolt3]

I like it, I have a couple of suggestions for a settings change and a wording change that might make sense to apply during the Trixie port though.

[adrelanos]

Regarding some comments in this pull request: How is this related to cold boot attacks? Maybe related to warm boot attacks? But I don't see how this helps with warm boot attacks.

[raja-grewal]

Yes you have made an excellent point that this is also relevant to warm boot attacks. I mistakenly agreed that it was just cold boot simply because I scarcely ever come across the "warm boot" phrasing.

Keep in mind that without immediate reboots, the system while powered on hangs forever with memory contents frozen till the user manually reboots.

The reason this is a vector for cold boot attacks is that someone can come and physically power down the system and immediately extract memory modules enabling the highest likelihood of forensic recovery. As explained by @ArrayBolt3 above.

The reason that this is also a warm boot scenario is that perhaps with some DMA method it may be possible to copy memory content since the motherboard is accessible.

By forcing instant reboots what we have done is at least begin wiping some memory contents that were previously frozen in place.

I updated this in the most recent commit, let me know what you think.

[ArrayBolt3]

By forcing instant reboots what we have done is at least begin wiping some memory contents that were previously frozen in place.

This makes me wonder if some form of RAM wiping that happens on bootup might be useful...