The purpose of this bootloader is to avoid executing malicious code sent over the internet, such as by a MITM attack.

The author explains that it does not attempt to defend against hardware attacks or attempts to replace the bootloader:

> SentinelBoot's threat model focuses on thin client devices which do not store their own OS and over-the-air updates (e.g. how phones are updated): both of these cases involve executable code being sent over a network, usually the internet. We ignore the risk of direct hardware modification, as an attacker can just swap out the bootloader (making any potential defence implemented by SentinelBoot in vain).

I'm sure that's part of the story, but there's tons of boring old company/government equipment out there in the world that wants secure boot too.

That'll happen with permissive licenses

That battle already happened, we already lost, and honestly, I still feel safer using my iPhone over a PinePhone.

> honestly, I still feel safer using my iPhone over a PinePhone.

But is that a result of it refusing to let you run whatever program you want, or your faith in its ability to sandbox programs regardless?

If someone physically steals my phone, they can’t install a keylogger that loads before the login screen.

The sandboxing actually works pretty well and serves a useful feature, the PinePhone doesn’t have sandboxing at all (and even Flatpak sandboxing often has massive holes punched through).

The iPhone has dozens, if not hundreds, of research organizations working on it to find bugs. Even Apple’s competitors like Google contribute. I have no assurance the PinePhone’s login screen doesn’t have an obvious buffer overflow.

If my iPhone does somehow get a virus, no virus has been found that can persist between reboots since iOS 9. Linux, persistence is the default.

If an iPhone app gains my PIN code, it’s bad but mostly meaningless to system integrity, which is forbidden at a kernel level from being tampered with by anything. If a Linux app gets your root password, or a privilege escalation bug is found in the many userspace utilities, daemons, or processes, you’re SOL.

The iPhone has hardware level features called “mailboxes” in the Secure Enclave, which enforce the limits for how often a PIN can be guessed; making a software bypass impossible and even a 4-digit code relatively safe. PinePhone doesn’t even have secure boot, so loading a tool that runs unlimited guesses could not be easier.

Do I need to go on?

You’re comparing a trillion dollar (of value) product to a thousand dollar one, and then implying the second is failing due to a technical issue.

Pine drops hardware and lets other folks do the software work.

To be quite fair, I think the pinephone is technically inferior in some ways; having a TPM and secure boot would let you make the device safer than is currently possible. But that's orthogonal to it being a walled garden; if users could run arbitrary apps downloaded off the internet, iPhones would still be safer, and if the next pinephone includes a TPM and user-controlled secure boot, it would have most of the same security properties while still being completely under the user's control.

PinePhone SoC (Allwinner A64) does have the hardware needed for verifying boot via TBBR. It's just that no person or distro uses it for that because the key can only be written once. Also IIRC it's vulnerable to bus snooping.

> > PinePhone doesn’t even have secure boot

If GP is correct about that, software won’t fix that limitation in PinePhone hardware. I expect the lack of a secure enclave is a similar story.

To a customer, it's irrelevant.

> Do I need to go on?

It would help; it feels like you're trying to argue in favor of a walled garden but only using arguments that are unrelated. Actually, it kinda feels like you might only be arguing that you think iPhones specifically happen to be really secure in a way that has nothing to do with user freedom at all.

In more details:

> If someone physically steals my phone, they can’t install a keylogger that loads before the login screen.

Fully mitigated by secure boot with user-controlled keys; unrelated to letting the user run whatever they want. Also, perfectly possible to mitigate on a pinephone by just reimaging everything except your encrypted home partition.

> The sandboxing actually works pretty well and serves a useful feature, the PinePhone doesn’t have sandboxing at all (and even Flatpak sandboxing often has massive holes punched through).

Yes, we agree that the sandbox matters... in fact, much of my point is that once you have a good sandbox it doesn't matter what the user wants to run inside it. (Also, you can use bubblewrap/firejail to sandbox things properly on Linux, it's just less common.)

> The iPhone has dozens, if not hundreds, of research organizations working on it to find bugs. Even Apple’s competitors like Google contribute. I have no assurance the PinePhone’s login screen doesn’t have an obvious buffer overflow.

Well that one's totally unrelated to letting users run whatever they want. At this point it almost feels like you're trying to just argue that iPhones are pretty robust and have completely given up on whether user control is relevant at all.

> If my iPhone does somehow get a virus, no virus has been found that can persist between reboots since iOS 9. Linux, persistence is the default.

Default in common distros, sure, but 1. still unrelated to walled garden, and 2. there are immutable distros if that's what you want.

> If an iPhone app gains my PIN code, it’s bad but mostly meaningless to system integrity, which is forbidden at a kernel level from being tampered with by anything. If a Linux app gets your root password, or a privilege escalation bug is found in the many userspace utilities, daemons, or processes, you’re SOL.

Is iOS somehow immune to privilege escalation bugs? Anyways, if you really want to lock down root selinux does exist, but also... what exactly are we protecting here? At the point where a program has the ability to impersonate the user including their password, we're at https://xkcd.com/1200/ and you might manage to protect the OS but if you lose all userspace what's the point?

> The iPhone has hardware level features called “mailboxes” in the Secure Enclave, which enforce the limits for how often a PIN can be guessed; making a software bypass impossible and even a 4-digit code relatively safe. PinePhone doesn’t even have secure boot, so loading a tool that runs unlimited guesses could not be easier.

Again, unrelated to user freedom; the only reason not to add a TPM to the pinephone is cost.

That's what it's for, make no mistake.

Those who sacrifice liberty for safety will receive and deserve neither.

Reminder that quote is so out of context that the actual meaning, as it was intended, is wildly different.

https://techcrunch.com/2014/02/14/how-the-world-butchered-be...

https://news.ycombinator.com/item?id=5268899

https://www.npr.org/2015/03/02/390245038/ben-franklins-famou...

I am sorry if I have caused any misunderstanding; the point I was trying to make is that, as ownership is a nebulous concept, yet one that must be protected, one with physical access to a device ought to be able to do whatever they want to it. To imply that bootloader locking is not primarily used to restrict what the owner of a device is able to do with it is disingenuous at best. I fundamentally disagree with the concept of bootloader locks in general under the idea that the evil that corporations are able to enact with them has historically far outweighed the real life security concerns that they actually protect users against. I understand this may be a controversial viewpoint but personally I feel (opinion) that the erosion of ownership is one of the most important issues we face today.

That shift has already started in various areas.

You see it with phones but also with cars where OEMs require Secure Boot enabled devices when possible. This ranges from the central unit to all small ECUs.

You can kind of see it pushed for desktops as the default mode but at least there for now you usually have a way to disable it.

For embedded devices though they never really provide a way to disable it. I think you could find a compromise where you could provide a physical method to disable it. If you disable it you clear all the DRM keys and other secrets. This way you can still protect against malicious updates for most users and tinkerers can do what they want once the company stops supporting it.

This was going to happen regardless. I believe Nvidia's RISC-V coprocessor ships with hardware fuses that serve more-or-less the same purpose.

If anything, it just makes me glad that RISC-V also has specs for UEFI-like interfaces.

Many (most) devices with secure boot have hardware fuses, but the software that reads them is usually broken. Rust and an eye towards sound cryptographic primitives (especially against side channels) will definitely go a distance towards protecting against this, although logic bugs are also quite common.

This bootloader doesn’t actually seem to be a real secure / trusted boot implementation anyway, just a thing that verifies updates.

What is the story with rust and cryptographic side channels? I imagine the layers of abstraction (e.g. an iterator may have arbitrary O) would make it harder to see those?

The layers don't really matter. Any side-effect or implementation detail (especially in a language with an optimizing compiler) is not a good protection against side channel attacks.

Where Rust (and most languages with a robust type system) can help prevent side channel issues is via typing - all cryptographic operations in a given library can be implemented with (for example), a TimingSafeU32 type that only implements constant-time operations (comparison, multiplication, addition, etc). This massively reduces the opportunity for mistakes. Traits make implementing this type of system much easier and more elegant.

`rust-timing-shield` and `subtle` are both a good example here, as well as really everything in https://github.com/dalek-cryptography .

I'd be more worried about early exits from loops in an iterator, e.g. if you had a .any() derived function, or short-circuiting logic in boolean operators with a lazily evaluated second parameter. A type system won't protect you from that.

Or maybe an early return and having an expensive destructor called as it goes out of phase with RAII