Every installation guide I read tells me to disable Secure Boot in firmware before installing, and then never mentions it again. It stays off.
That feels like disabling a security feature permanently to solve a one-time problem, and I would rather understand what it does before accepting that.
What is it actually protecting against, and is running with it enabled realistic?
What it protects against is narrow and real: code running before the operating system starts.
The firmware checks that the bootloader it is about to run carries a signature from a key it trusts, and the bootloader checks the kernel in turn. The threat model is malware that installs itself into the boot path, where it loads before any antivirus, any disk encryption prompt and any security software, and is therefore very hard to detect or remove.
That is a narrow class of attack and a serious one, and it is worth noting what it does not protect against: essentially everything after boot. It is not a general-purpose defence and it does nothing about ordinary compromise.
Running with it enabled is entirely realistic. Most mainstream distributions ship a signed bootloader precisely so this works, and they install with it on.
The middle path worth knowing about: enrol your own key.
You generate a key, enrol it in firmware, and sign your own bootloader and modules with it. Then Secure Boot is enabled and trusting you rather than a third party, which is arguably the correct arrangement for a machine you own.
There are tools that automate the signing on module rebuilds so it is not a manual step every kernel update. Setting it up is an afternoon, and after that it is invisible.
It is also the only option that gets you Secure Boot on a distribution with no signed loader, so for a rolling distribution it is the answer rather than a curiosity.
One practical note before changing it in either direction: know how to get back into firmware, and check whether disk encryption is involved.
On some machines, changing Secure Boot state affects the platform module that may be holding a disk encryption key, and the machine then asks for a recovery key you have never seen. That applies to both Windows and Linux setups using it.
So: find the recovery key first, write it down somewhere off the machine, and then change the setting. Doing it the other way round is a memorable evening.
@firmware_fikri · 5d ago
Why the guides tell you to turn it off anyway, and it is not laziness:
Out-of-tree kernel modules. Anything not built as part of the signed kernel — proprietary graphics drivers, virtualisation modules, some hardware drivers — has to be signed too, or the kernel refuses to load it. On distributions with tooling for this it is handled automatically. On others you enrol your own key and sign modules yourself, and that is a real chore.
Rolling and community distributions often do not ship a signed bootloader at all, so the only route is enrolling your own keys.
Hibernation and some kernel features are restricted under the lockdown mode that usually accompanies it.
Dual boot ordering breaks in confusing ways after firmware updates.
So the honest guidance: on a mainstream distribution with open drivers, leave it on and you will not notice. If you need proprietary drivers or run a distribution without a signed loader, turning it off is a defensible choice — and make it a decision rather than a default.
Reply
Report