"Secure boot" is a perfectly fine and desirable thing. It makes evil maid attacks more difficult and has many other benefits. The problem is that the current c

"Secure boot" is a perfectly fine and desirable thing. It makes evil maid attacks more difficult and has many other benefits. The problem is that the current crop of "secure boot" implementations focuses squarely on the average consumer that wants to delegate trust to the manufacturer, and, at best, only pays lip service to users who want to control their own hardware (see: Pixel devices and the like with closed bootloaders/TrustZone but an escape hatch for the OS) or nothing at worst. Almost every "secure boot" CPU in modern smartphones and such is already user-control-friendly, it's just that they aren't being shipped that way. They get locked down at the factory. The CPU architecture has little to do with any of this. If you want an example of what an unlocked secure boot device is, look at the Nvidia Tegra devkits. Those come without the public key fuses blown. You can burn in your own public key and then they will only ever run firmware you signed, forever. ARM devices without secure boot, or with user-control-assertable secure boot exist. And RISC-V devices locked down at the factory will exist.