We need to add uefi support
this includes boot from uefi and secureboot
Description
Details
- Version
- -
- Is it a breaking change?
- Unspecified (possibly destroys the router)
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Needs testing | FEATURE REQUEST | None | T858 Full UEFI support | ||
Resolved | FEATURE REQUEST | UnicronNL | T859 boot from UEFI | ||
Needs testing | FEATURE REQUEST | c-po | T861 add secure boot support | ||
Resolved | FEATURE REQUEST | UnicronNL | T947 Installer rework for uefi backed installation |
Event Timeline
What happens on Hypervisors not supporting UEFI or older Hardware Platforms without UEFI?
I never understood why this is so common as I see not mich benefit.
Most of current distros can boot on legacy systems (e.g. with BIOS) and also UEFI
since many new server platforms switched to uefi we need to cover that.
Most of them can be switched from UEFI to legacy BIOS, however there are devices that not support such change
UEFI is not difficult.
SecureBoot *is* difficult, as we're compiling our own kernel, and someone needs to get some signing keys blessed by Microsoft to sign the kernel and modules so they can be loaded by secureboot.
I don't think we should support restricted boot. As per MS's own specification, all x86 boards should allow the user to disable it, and to my knowledge, they all do.
@dmbaturin I think you missing purpose, in some environments (e.g. with high-security requirements ) it may be required
if we can we should support it
Just commenting, UEFI boot is now working (tested in hyper-v gen2 VM with 1.2 20190520). Personally, I care from a performance perspective: hyper-v gen2 network adapters greatly outperform the "legacy network adapter" available to gen1, which is a full software emulated NIC.
Secureboot, as @xrobau said, is trickier. You need Microsoft approve a public EV code signing cert for the Microsoft UEFI Certificate Authority. This is what enables distro's to produce signed code that hardware UEFIs and Hyper-V secure boot will support. Once you have a code signing cert, signing builds should be trivial. At the office, we actually sign even simple automation scripts we write up for clients. Overkill, but it made the auditors happy in certain environments. Just need to properly secure the code signing keys from unauthorized use.
Unfortunately, the Microsoft instructions for starting down this path are out of date. https://blogs.technet.microsoft.com/dubaisec/2016/03/14/diving-into-secure-boot/ references https://sysdev.microsoft.com which no longer resolves.
*EDIT: insane grammar fixed
Where possible, we can consider MBR+UEFI dual boot, which also exists in most distributions
Both UEFI and MBR boot modes are supported currently.
As a replacement for keys from Microsoft, it is possible to use our keys and ask users to install CA into a MOK database.