Platforms, Trusted Platforms and Windows 11
Windows hardware requirements have always promoted confusion, sand this time is no different…
When Windows 8 was announced, there was a concern that Microsoft would use Secure Boot, an optional feature of the then new UEFI (Universal Extensible Firmware Interface), to restrict the installation of other operating systems. Secure Boot only allows booting EFI images that have been signed by a key enrolled in the UEFI. Since almost all hardware ships with a public signing key from Microsoft, it’s easy to see where this concern came from. However, to help Linux distros (or any software that needed its own bootloader) deal with Secure Boot, Microsoft used its magic key to sign a small program (they probably wouldn’t sign something big and complicated) called Shim.
Shim is a first-stage bootloader used by many distros (including Debian and Ubuntu) to launch their own (second stage) bootloaders. Secure Boot works by each stage checking the signature of the following one before executing it, thus establishing a root of trust back to the original signing key. So distributions can embed their own keys into Shim, and have this distro-specific Shim package signed by Microsoft. Shim can then check the GRUB EFI image, signed by the distro key, and boot can proceed. It’s possible to sign kernel images too, as well as subsequently loaded modules and firmware, so if you trust cryptography and the Microsoft Signing Authority, then Secure Boot makes it really hard for malware to be loaded anywhere in the early boot process.
A question of trust
Of course, not everyone’s going to trust Microsoft, or indeed Secure Boot. And that’s okay, because in 2013 when Microsoft stipulated that “Windows 8 Ready” hardware should ship with Secure Boot enabled, it also made the provision that it should be possible to disable it, and also that it should be possible for users to install their own MOKs (Machine Owner Keys) and use them to sign whatever bootloader they wanted, so that ultimate trust (but also ultimate responsibility) lay with the user.
“Windows 10 Ready” hardware was subject to similar conditions, except the requirement that Secure Boot be mutable was reduced to a suggestion. Still, we’ve never come across a single Windows 10 machine where Secure Boot could not be disabled. And if you build your own systems, then you have nothing to worry about. The “Ready” conditions are for OEMs that ship systems with the OS already installed. Now with Windows 11 upon us, it’s no longer Secure Boot clauses that are being scrutinised , but those relating to TPM chips.
Trusted Platform Module (TPM) chips are tiny processors that have a small privileged memory store, which applications can use to store keys, authentication data or anything that they don’t want other applications nosing at or tampering with. Besides some (fairly strict) minimum hardware specifications, for a PC to officially support Windows 11 it must also support TPM 2.0. At the moment, it’s still possible to install Windows 11 via the official ISO if your device doesn’t meet the TPM (or other) requirements, but Microsoft says such installations are unsupported, and may not be privy to security updates further down the line. Indeed, at the time of writing we’ve seen Insider builds of Windows 11 running on a Pi 400, as well as a Nokia Lumia 950XL (one of the last devices to run Windows Phone).