Linux and Secure Boot. An error that we cannot repeat

At previous article I recalled a precedent to Microsoft's requirement to require the TPM version 2 module to be able to use Windows 11. I am referring to the requirement that computers with Windows 8 pre-installed use UEFI instead of BIOS for the bootloader and that the Secure Boot module was pre-installed.  Now I am going to talk about the, in my opinion, wrong way in which Linux dealt with the problem.

Linux and Secure Boot

Secure Boot requires that each program that is started has a signature that guarantees its authenticity stored in the database of the non-volatile memory of the motherboard. There are two ways to appear in that database. Whether it is included by the manufacturer or included by Microsoft.

The solution reached by some Linux distributions with Microsoft was that this company accepted the signature of a binary that would be in charge of launching the boot loader of each distribution. These binaries were made available to the community.

Later, the Linux Foundation would launch a generic solution that can be adopted by all distributions.

Looking for a better solution, a Red Hat developer suggested the following to Linus Torvalds:

Hi Linus,

Can you include this patch set please?

Provides a function by which keys can be dynamically added to a kernel running in secure boot mode. To allow a key to be loaded under such a condition, we require that the new key be signed by a key that we already have (and that we trust), where the keys we "already have" could include those embedded in the kernel, those in the UEFI database and those of the cryptographic hardware.

Now "keyctl add" will already handle X.509 certificates that are signed like this, but Microsoft's signing service will only sign executable EFI PE binaries.

We could require the user to reboot into the BIOS, add the key, and then switch back, but in some circumstances we want to be able to do this while the kernel is running.

The way we have come up with to fix this is to embed an X.509 certificate containing the key in a section called ".keylist" in an EFI PE binary and then get the Microsoft signed binary.

Linus word

Linus's response (Let's remember that it was before his spiritual retreat to reconsider his attitude in relationships with other people), was the following:

NOTICE: The following text includes profanity

Guys, this is not a cock sucking contest.

If you want to use the PE binaries, please continue. If Red Hat wants to deepen its relationship with Microsoft, that's * your * problem. That has nothing to do with the kernel that I maintain. It is easy for you to have a signature engine that parses the PE binary, verifies the signatures, and signs the resulting keys with your own key. The code, for God's sake, is already written, it's in that damn inclusion request.

Why should I care? Why should the kernel care about some idiotic "we only sign PE binaries" stupid? We support X.509, which is the standard for signing.

This can be done at the user level. There is no excuse to do it in the kernel.

Linus

My opinion is that Linus was correct for once. In fact neither the Linux Foundation nor the distributions should have been blackmailed by Microsoft.  It is true that users could have been lost. But, as it turned out later, Windows 8 was a failure and XP continued to reign for much longer.

The reality is that when Microsoft is faced with a battle, it is forced to abide by the standards. It happened when she failed with SIlverlight and was forced to adopt the HTML 5 web standard. It happened when she had to abandon web rendering engine development and base Edge on Chromium.

Nor should we forget that to attract programmers it had to include nothing less than the ability to run Linux on Windows.

Linux distributions are in a better position than ever to offer users an alternative to continue using perfectly functional hardware.