Many Secure Boot implementations let you load your own keys. The "removing the owner from the equation" thing is not an issue with Secure Boot, but with particular manufacturers.
> The better place for signed loader verification is in the on-disk bootloader stub.
That is already part of the Secure Boot. But who verifies the bootloader stub? The point is that you can't trust anything on the disk.
> Any bootloader relies on a chain of trust. If the on-disk (OS) portion of that fails (incidentally, the biggest attack surface) and is vulnerable (likely - proprietary software can be fuzzed like any other), then the hardware-linked protection is at best annoying to the actual hardware owner.
Firmware verifies the (on-disk) bootloader, bootloader verifies the kernel, kernel verifies the drivers, and so on. The chain of trust is there.
> The better place for signed loader verification is in the on-disk bootloader stub.
That is already part of the Secure Boot. But who verifies the bootloader stub? The point is that you can't trust anything on the disk.
> Any bootloader relies on a chain of trust. If the on-disk (OS) portion of that fails (incidentally, the biggest attack surface) and is vulnerable (likely - proprietary software can be fuzzed like any other), then the hardware-linked protection is at best annoying to the actual hardware owner.
Firmware verifies the (on-disk) bootloader, bootloader verifies the kernel, kernel verifies the drivers, and so on. The chain of trust is there.