Provide Secure Boot support

As discussed in FS#53864 it would be beneficial to provide Secure Boot support out-of-the-box (for systems that are booted for the first time and have Secure Boot enabled or for systems where Secure Boot can not be disabled).

One of the outcomes of the above discussion has been that likely the only viable option for this use-case is to apply for a distribution certificate and use a signed shim (see this mailing list discussion by @diabonas for reference).

added hinthelp-wanted scopeenhancement labels

assigned to @diabonas

mentioned in issue #159 (closed)

mentioned in issue #156 (closed)

marked this issue as related to #174 (closed)

Discussion in FS#53864 mentions borrowing shim and GRUB from older Ubuntu releases. The point in using older release is to have GRUB load unsigned kernels. Unfortunately, this only works on old enough systems, i.e. such systems where the Secure Boot certificates are fairly old and the revocation list does not include older Ubuntu signatures. For example HP 250 G4 Notebook PC with Born On Date 05/10/2016 running Windows 10 with Secure Boot enabled no longer authenticates older Ubuntu signatures.

While surprising at first, the fact that older Ubuntu releases no longer authenticate on up to date Secure Boot implementations pretty much matches shim-review rules, i.e. "Were old shims hashes provided to Microsoft for verification and to be added to future DBX updates?".

The HP 250 G4 Notebook PC is annoying in that while the BIOS Setup Utility has option to disable Secure Boot, disabling it on already enrolled system has no effect, i.e. the reboot after Save and Exit has the Secure Boot enabled back. Also enrolling hash in shim does not work on this system. Therefore it is impossible to simply boot portable Arch Linux from USB SSD on such system while it is possible to boot latest Ubuntu live cd (borrowing just the shim and GRUB from Ubuntu live cd is not enough because the kernel and/or chainloaded EFI bootloader must be signed).

Applying for distribution certification seems to be the best option. However, the signed bootloaders have to ensure that only signed kernels are booted when Secure Boot is enabled (while technically possible, the certificate cannot be used to sign bootloader that will unconditionally boot unsigned kernels - unless you want the certificate to be revoked).

For users willing to run their own bootloader and/or kernel and who are able to enroll their own MOK key, the MOK is probably the best option. Unfortunately, Arch Linux currently lacks proper support for MOK and the signing has to be done either manually or with (more or less nasty) custom alpm hooks. Using MOK is much better than enrolling individual hashes, because the hashes are included in Non-Volatilve memory that has limited capacity (removing old hashes from the Non-Volatile memory is not fun).

Another option for users who want/have to have Secure Boot enabled (e.g. to dual boot Windows), is to run mokutil --disable-validation. This allows unsigned bootloaders and kernel images to boot as long as the shim itself is signed (e.g. when signed shim is borrowed from other distribution). However, running mokutil --disable-validation requires being able to boot some distribution in the first place (and therefore having Arch Linux certificate is best option).

added scopefeature label and removed scopeenhancement label

added statusconfirmed label