> The people here that claim "secureboot prevented that". No, it didn't. A simple call to sbctl to sign the rootkit is missing, because, as every Linux device, you will have to have the signature keys available locally. Otherwise you can never update your kernel.
If, hypothetically, you were using a system without custom keys, e.g. with a third party kernel trusted via the Microsoft / Red Hat shim program, [1] wouldn't you be safe, so long as secure boot was enabled? The bootkit would not be able to sign itself with a trusted key since the private key would never exist on the system to begin with.
Obviously, I'm aware that this approach has other problems and has had vulnerabilities in the past.
You don't need to do your signing locally, it is possible to build your network around a build machine that does the signing for you. That being said, SecureBoot has always been security theater for anyone that isn't a major OS manufacturer or industry player. The fact is, as soon as cryptography comes into the picture the majority of the computing populace have already left the conversation.
If, hypothetically, you were using a system without custom keys, e.g. with a third party kernel trusted via the Microsoft / Red Hat shim program, [1] wouldn't you be safe, so long as secure boot was enabled? The bootkit would not be able to sign itself with a trusted key since the private key would never exist on the system to begin with.
Obviously, I'm aware that this approach has other problems and has had vulnerabilities in the past.
[1] https://wiki.ubuntu.com/UEFI/SecureBoot