Unfortunately, in practice that's what it often does, and the user is considered an "attacker". All this complexity is scary, and threatens to turn PCs into locked-down devices like the mobile world has done. I wonder if pre-UEFI/pre-ME x86 systems will become more valuable sometime in the future, because of this.
I used to wonder, even before iPhone and Android, how far away we were from a world where most “computers” were effectively unconfigurable and unprogrammable, and actual programmable computers like the ones we’re used to became relatively rare “makers tools”. That does seem to be the way things are headed; there may come a point in our lifetimes where almost nobody has a “programmers computer” in their house.
"Lockdown: The coming war on general-purpose computing"
Note that the UEFI spec for x86 requires user-modifiable keys (after public outcry), but the spec for ARM requires NO user-modifiable keys. (Edit: actually this may only be a Windows requirement)
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.
I had the same worry, some 15 years ago I think it was the top of the "they're trying to lock PCs down 100%". Today I don't worry so much
You need to put the device into setup mode first, which should be possible by disabling secure boot then deleting the platform key. Then you can update the DB, then KEK and finally PK using keytool.efi. There's many guides on the process, see for example: https://blog.hansenpartnership.com/owning-your-windows-8-uef... and https://www.rodsbooks.com/efi-bootloaders/controlling-sb.htm....
Specifically, what I'd do is: disable secure boot, copy shell.efi and keytool to the ESP, add a boot entry for the shell.efi entry, always useful, then boot to it, run keytool, clear the PK - voila you are in setup mode and should be able to change everything.
Be aware that once you set a platform key, updates to any key database are checked for valid signatures. Updates to the KEK must be signed by PK, updates to the DB, DBX must be signed by the KEK, etc. If there's no dialog, you might also want to back up the keys, if you want to set the machine back to its factory default setting.
I can imagine Microsoft might not have enabled this level of control for their surface devices, although as I understand their HCK, they should. Perhaps they exempt themselves :(
Maybe Apple’s true worry might be revealed by considering the difference between what they allow and what they prevent. Apple allow you to have a wholly-Linux UX on an Apple laptop; but they don’t allow Linux developers to run a Linux kernel directly on Apple hardware.
Maybe what they’re really concerned about is Linux having an easy testbed for developing MacBook hardware/peripheral drivers, such as for the T2, such that people could build apps in other OSes that take advantage of the touchbar, and thus in some way “commoditize” one of the costlier USPs of macOS?
What leads you to believe anyone at Apple spent even 5 minutes thinking about linux support at any point in time?
It is a testament to how far Linux on the desktop has come that our first assumption when Linux doesn't boot on a new machine is "The megacorp is using secret cryptography" and not "eh, missing drivers."
And some vendors actually help with the development of workarounds for their broken drives, and push out firmware fixes when possible so that the workarounds can be disabled on newer or updated devices.
It installs a minimal (@core-only in 'kickstart' parlance) Fedora with Secure Boot, which you can verify by `dmesg | grep Secure` once the guest boots.
I wrote this script on a Fedora 29 host, with KVM (the Kernel-based Virtual Machine), libvirt, QEMU and OVMF / EDK2 packages.