Uhm, these things don't really take away your control, rather, they shift it from you to you.
The software you boot sets up some state and then toggles a bit, and after that something can't be changed. The state is secure against much modification after that time, but not before that time.
The "you" that boots the device are in control, and the "you" that uses the device after that have exactly what "you" set up at boot time, neither more nor less. If both "you" are the same person, then there's no loss of control.
But of course they're often not really the same person. If you want to boot a Microsoft-signed image, the party that boots is more or less Microsoft, not you personally. But in that case, you also want to use that Microsoft-signed OS, right? So the shift towards boot-time control is then a shift from mostly-Microsoft use-time control to mostly-Microsoft boot-time control. Mostly Microsoft here, mostly Microsoft there, even if the two mostlies aren't quite the same percentage it's difficult to regard this as a significant loss of control.
How so? Redefines from what to what? Please elaborate.
Perhaps you mean that if you, as owner and legitimate user of a device, are able to perform a particular change only during a brief window of time rather than at any time of your choosing, then that limits your control over the device? If so, then my answer is yes, certainly it does. But it also limits the access of anyone who impersonates you (such as the evil exploity javascript I make your browser execute).
You're wrong because the bootloader is more often locked than not, and there are various other nefarious controls in place that prevent you from doing it without voiding your warranty, such as one-time fuses.
In theory, yes, you could implement it like you said, but that's not what happens in practice nor the direction we've been tending towards in recent times.
> The "you" that boots the device are in control, and the "you" that uses the device after that have exactly what "you" set up at boot time, neither more nor less. If both "you" are the same person, then there's no loss of control.
How is it orthogonal? Okay, we're not strictly speaking of only bootloader locking, but of boot-time-control locking.
That CPU is set up by the kernel at boot time, given the code to run, then some hardware bits are toggled such that the main CPU can't write later, it can only access the separate CPU via a defined API.
The kernel could do the same with an in-kernel process. It wouldn't have quite the same depth of defense against userspace sandbox escapes, but could be done. That's roughly how /dev/random was implemented for many years.
Look at the APIs provided — it's nothing new. It's nothing OSes haven't provided before, it's just further removed from a Chrome/FF/Safari sandbox escape, because overcoming the write-once hardware toggles is harder than getting kernel read/write primitives for a sandbox privilege escalation.
The software you boot sets up some state and then toggles a bit, and after that something can't be changed. The state is secure against much modification after that time, but not before that time.
The "you" that boots the device are in control, and the "you" that uses the device after that have exactly what "you" set up at boot time, neither more nor less. If both "you" are the same person, then there's no loss of control.
But of course they're often not really the same person. If you want to boot a Microsoft-signed image, the party that boots is more or less Microsoft, not you personally. But in that case, you also want to use that Microsoft-signed OS, right? So the shift towards boot-time control is then a shift from mostly-Microsoft use-time control to mostly-Microsoft boot-time control. Mostly Microsoft here, mostly Microsoft there, even if the two mostlies aren't quite the same percentage it's difficult to regard this as a significant loss of control.