5 ms·

Congratulations on the development. Part of me is concerned that this will be used to push devices that cannot be unlocked and tinkered with by end users, reduc

Congratulations on the development. Part of me is concerned that this will be used to push devices that cannot be unlocked and tinkered with by end users, reducing their technological freedom.

mouse_ 2y ago
That's what it's for, make no mistake. Those who sacrifice liberty for safety will receive and deserve neither.
- gjsman-1000 2y ago
  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-benjamin-franklins-quote-on-liberty-vs-security/ https://techcrunch.com/2014/02/14/how-the-world-butchered-be... https://news.ycombinator.com/item?id=5268899 https://news.ycombinator.com/item?id=5268899 https://www.npr.org/2015/03/02/390245038/ben-franklins-famous-liberty-safety-quote-lost-its-context-in-21st-century https://www.npr.org/2015/03/02/390245038/ben-franklins-famou...
  - mouse_ 2y ago
    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.
  - Z0QinrgF 2y ago
    [dead]
gjsman-1000 2y ago
[flagged]
- yjftsjthsd-h 2y ago
  > 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?
  - gjsman-1000 2y ago
    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?
    - mixmastamyk 2y ago
      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.
RsmFz 2y ago
That'll happen with permissive licenses
oconnor663 2y ago
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.
Aurornis 2y ago
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).
almatabata 2y ago
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.
talldayo 2y ago
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.
- bri3d 2y ago
  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.
  - throwawaymaths 2y ago
    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?
    - bri3d 2y ago
      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 https://github.com/dalek-cryptography .
      - throwawaymaths 2y ago
deleted 2y ago
[deleted]

Congratulations on the development. Part of me is concerned that this will be used to push devices that cannot be unlocked and tinkered with by end users, reducing their technological freedom.

mouse_ 2y ago

That's what it's for, make no mistake. Those who sacrifice liberty for safety will receive and deserve neither.

gjsman-1000 2y ago
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-benjamin-franklins-quote-on-liberty-vs-security/ https://techcrunch.com/2014/02/14/how-the-world-butchered-be... https://news.ycombinator.com/item?id=5268899 https://news.ycombinator.com/item?id=5268899 https://www.npr.org/2015/03/02/390245038/ben-franklins-famous-liberty-safety-quote-lost-its-context-in-21st-century https://www.npr.org/2015/03/02/390245038/ben-franklins-famou...
- mouse_ 2y ago
  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.
- Z0QinrgF 2y ago
  [dead]

gjsman-1000 2y ago

[flagged]

yjftsjthsd-h 2y ago
> 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?
- gjsman-1000 2y ago
  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?
  - mixmastamyk 2y ago
    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.

RsmFz 2y ago

That'll happen with permissive licenses

oconnor663 2y ago

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.

Aurornis 2y ago

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

almatabata 2y ago

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.

talldayo 2y ago

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.

bri3d 2y ago
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.
- throwawaymaths 2y ago
  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?
  - bri3d 2y ago
    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 https://github.com/dalek-cryptography .
    - throwawaymaths 2y ago

deleted 2y ago

[deleted]