Red Hat Working On Delayed Module Signature Verification To Speed-Up Linux Boot Times

[phoronix]

Phoronix: Red Hat Working On Delayed Module Signature Verification To Speed-Up Linux Boot Times

A Red Hat engineer has published patches to optionally allow delayed module signature verification in an effort to have a secure Linux system but to allow for faster boot times...

https://www.phoronix.com/news/Linux-Delay-Module-Verification

[Kjell]

Benchmark?

[skeevy420]

Let's assume everything else is up to snuff and hasn't been tampered with so we can defer tamper checking.

That doesn't sound like an exploit waiting to happen

I know, I know, it's for debugging and testing and shouldn't be used outside of that.

This parameter enables delayed activation of module signature checks, deferring the process until userspace triggers it. Once activated, this setting becomes permanent and cannot be reversed. This feature proves valuable for incorporating unsigned modules within initrd, especially after bootloader verification. By employing this option, boot times can be quicker.

Does that include subsequent boots? I really hope not...that'd make this less of a debugging option and more of a "How to permanently exploit Linux with this one little trick" option since the word permanent has certain implications.

It's really not as bad as you're making it sound.

The module isn't going to say no. It could, but it's not going to. Because of the implication.

[RahulSundaram]

Does that include subsequent boots? I really hope not...that'd make this less of a debugging option and more of a "How to permanently exploit Linux with this one little trick" option since the word permanent has certain implications

Permanent in this context just means you cannot runtime toggle it. This is true for secure boot options in general because runtime toggles are prone to exploitation. It doesn't impact the next boot unless you set it in your bootloader.

[skeevy420]

Permanent in this context just means you cannot runtime toggle it. This is true for secure boot options in general because runtime toggles are prone to exploitation. It doesn't impact the next boot unless you set it in your bootloader.

That's what I initially assumed until I thought too hard about it. They should really update that with "until the system is reinitialized." or restarted, or rebooted, or whatever appropriate technical jargon works.

[andyprough]

Back when I was a younger pup, RedHat was screaming to everyone that would listen that the reason we NEEDED systemd was to improve boot times.

Of course systemd since that time has lost every head-to-head boot speed test I've ever seen against the smaller, lighter alternatives.

Yes we needed faster boot times, but RedHat merely used that perceived need as a Trojan Horse to push a trainload of bloated enterprise nonsense onto the desktop users and to cut off all rational thought by the major desktop distros of exploring reasonable alternatives.

Of course none of that has anything to do with "Delayed Mode Signature Verification" [or does it???], but it seems like an opportune moment for me to rant about the enormous opportunity costs that have been sunk into following RedHat's lead.

[Jakobson]

Let's assume everything else is up to snuff and hasn't been tampered with so we can defer tamper checking..

If one can assume nothing has been tampered then no signature checking is needed.

[RahulSundaram]

Back when I was a younger pup, RedHat was screaming to everyone that would listen that the reason we NEEDED systemd was to improve boot times

Nope. Boot speed was never the sole or only justification. From the initial proposal

Note that in the long run systemd will provide quicker boot up, but completing that will take more work, since some additional changes to our early boot-up need to take place such as splitting up rc.sysinit. However the focus of systemd is primarily doing things right, and not exclusively on speed.

[andyprough]

Nope. Boot speed was never the sole or only justification.

Not interested in your nonsense today Rahul, telling me I wasn't there and my eyes never saw what they clearly saw. I know that there were other reasons, there were numerous security reasons, but the number one item that was pounded relentlessly was boot speed.

Of course despite the fact of booting various groups of activities in parallel, the real reason our boot speeds today are measured in seconds instead of minutes is because we are all now using modern chips, modern chipsets, faster ram, and our nvme ssd's are all exponentially faster than our old 5400 rpm spinning disk hard drives used to be. Drag out your old minitower from 2003 and if you can somehow squeeze a modern bloated systemd distro on it, you'll see that the boot speeds will still be measured against the time it takes to brew a cup of coffee.

[geearf]

Not interested in your nonsense today Rahul, telling me I wasn't there and my eyes never saw what they clearly saw. I know that there were other reasons, there were numerous security reasons, but the number one item that was pounded relentlessly was boot speed.

Was it touted as faster than UpStart? I don't remember.

Of course despite the fact of booting various groups of activities in parallel, the real reason our boot speeds today are measured in seconds instead of minutes is because we are all now using modern chips, modern chipsets, faster ram, and our nvme ssd's are all exponentially faster than our old 5400 rpm spinning disk hard drives used to be. Drag out your old minitower from 2003 and if you can somehow squeeze a modern bloated systemd distro on it, you'll see that the boot speeds will still be measured against the time it takes to brew a cup of coffee.

I'm not 100% about that, since moving to Ryzen my boot time is a lot slower because the UEFI takes a hell lot longer to start than my old haswell platform did (which was similar to previous ones I'd say). I actually feel that lately my boot got a lot slower, but not sure where from. You're making me want to investigate.