Hacker News new | ask | show | jobs
by Arnt 1422 days ago
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).
1 comments
feanaro 1422 days ago
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.

link
Arnt 1422 days ago
Bootloader locking is orthogonal to whether there's a second CPU like that Pluton in the system.
link
feanaro 1422 days ago
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.

link
Arnt 1418 days ago
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.

link