If secure boot isn’t designed to defend against hardware attacks then why is their such emphasis on security? Does this long, complicated boot procedure somehow protect against remote motherboard firmware loading?
The idea was to prevent bootkits. In UEFI the last phase, the complete UEFI phase after DXE and all the parts that come before it, is to read the EFI boot options from NVRAM. If there are no configured bootloaders, EFI volumes are read from GPT disks (and el-torito extensions to iso9660 cd roms) and one of these is booted - one of:
for x86-64, x86 and AArch64 (64-bit ARM) respectively. These are if you like the default boot paths on EFI volumes.
On pre-UEFI IBM-compatible systems, the equivalent was to look for the master boot record on a disk (or equivalent on iso9660 el-torito extensions). The MBR should end with 0x55 0xAA in the first 512 bytes of the disk - if these bytes are set, the whole thing is loaded into RAM at 0x7c00 and executed - in real mode, full segmented addressing and the A20 line not set, meaning you have only 1MB of RAM to play with until you get set up. No verification was done for this at all.
In spite of the complexity of the process, it was possible to create a "bootkit" simply by overwriting that MBR sector of the disk with custom code. This way you could modify the operating system before it had a chance to load, invalidating any security guarantees it could possibly give.
The equivalent in UEFI terms is to ask for the EFI variables to change, or replace one of those specified files. This will enable you to take control before the system starts - there's plenty of articles on hooking ExitBootServices to modify the system.
With UEFI's Secure Boot function turned on, even if you can persuade the operating system to overwrite those binaries or drop a custom one, the UEFI firmware will check the digital signature (or hash) before executing the code. It's exactly the same defense as driver signing - unsigned code is not allowed to run.
This isn't a complete solution. As the author notes, parts of flash may be unsecured and drivers may provide the facility to write to it in an unrestricted fashion, allowing the chain of trust to be compromised earlier. It's also possible to attack physically. There are all kinds of issues with CPU security.
On x86 systems, Microsoft's own compatibility guidelines for PCs mandate the ability to change the platform owner key, KEK, DB and DBX keys. The parent comment on lockdown is a valid concern (on Microsoft's ARM platforms, no change is possible) but at least for PC hardware it is possible to load your own keys and render Windows unable to boot.
