[feanaro]

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.

[Arnt]

Bootloader locking is orthogonal to whether there's a second CPU like that Pluton in the system.

[feanaro]

To quote you:

> 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.

[Arnt]

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.