3 ms·

The Librem 5 is not as open or libre as its marketing has tried to insinuate, simply having its binary blob signed and validated firmware saved in write-protect

The Librem 5 is not as open or libre as its marketing has tried to insinuate, simply having its binary blob signed and validated firmware saved in write-protected read-only memory and loaded by a secondary coprocessor to exploit a loophole in the definiton of "libre" hardware to allow it to qualify for the FSF's definiton of "Free" hardware. This renders the firmware unupdateable without shorting a connection. In the event a vulnerability is discovered in the modems or radios, the firmware cannot be updated without physically dismantling the phone. Firmware initialization is also no longer under the control of the host operating system because the initialization is carried out from outside the OS: changing or updating software on the host will not address these design defects. Although the modems and radios are not attached to the host via DMA, they rely on USB for isolation, which simply shifts the trust from the kernel driver to the kernel USB stack, and USB was never designed with distrusting the device plugged into it in mind unlike SMMU/IOMMU, which is specifically designed to mitigate unconstrained DMA. Current releases of the Librem 5 have been plagued by thermal throttling issues and poor battery life which in some cases has clocked in at less than 1 hour at idle. The Librem 5 does not even support software encryption and no progress has been made toward adding even LUKS encryption. The Librem 5 lacks a secure element for any hardware binding on the encryption and so would be entirely dependent on software-only encryption. The rebranded version of Debian that the Librem 5 uses as an operating system uses the same security model as the desktop stack, which is a perimeter or "all or nothing" security model. In the future, applications may be installed utilizing FlatPak. The threat model and measures FlatPak takes to meet it are as of yet unclear and uncertain. From https://github.com/Peter-Easton/GrapheneOS-Knowledge/blob/master/GrapheneOS-vs-Others.md https://github.com/Peter-Easton/GrapheneOS-Knowledge/blob/ma... which may be mildly out of date — but I doubt it. tl;dr Wake me up when you have an IOMMU!

qchris 6y ago
Thanks for the info, I hadn't heard about the USB isolation architecture issue. I'm not sure about the status of LUKS on PureOS, but I know that Mobian supports it and there is a supported build of Mobian for the Librem 5. First-hand, I've encrypted my Pinephone image, but don't have a Librem 5 so can't independently confirm that it actually includes that during the eMMC flashing process, although I don't have a reason to believe elsewise. Not sure if it's bad practice to share, but then what options do you use? If Debian's security model isn't enough, do you roll your own Linux base from something else instead? What kind of hardware is there as an alternative?
- kop316 6y ago
  Considering most of his other post is factually incorrect and/or out of date, I am skeptical of the claim to be frank.
  - atat7024 6y ago
    "You're wrong!" I can play that game, too!
    - kop316 6y ago
      Skeptical != wrong https://www.merriam-webster.com/dictionary/skepticism https://www.merriam-webster.com/dictionary/skepticism https://www.merriam-webster.com/dictionary/wrong https://www.merriam-webster.com/dictionary/wrong If there are factual in accuracies with my claims, I am happy to be proven wrong. That's how I learn! I just need proper citations.
  - fsflover 6y ago
    Are you skeptical about bad security of USB? Here you go: https://www.qubes-os.org/doc/device-handling-security/#usb-security https://www.qubes-os.org/doc/device-handling-security/#usb-s....
    - kop316 6y ago
      I'm skeptical of that person's claims, primarily because the document the individual sourced as "fact" was riddled with factual errors. I don't know enough about USB security to make a judgement one way or another. Thank you for this source, I'll check it out!
      - kop316 6y ago
        So in reading that overview, the same attacks that would apply to USB apply PCIe: > The connection of an untrusted USB device to dom0 is a security risk since the device can attack an arbitrary USB driver (which are included in the linux kernel), exploit bugs during partition-table-parsing or simply pretend to be a keyboard. This would be the same for any PCIe device. PCIe does not have any cryptographic authentication scheme that I am aware of, and PCIe device drivers are likewise in the linux kernel. > The whole USB stack is put to work to parse the data presented by the USB device in order to determine if it is a USB mass storage device, to read its configuration, etc. This happens even if the drive is then assigned and mounted in another qube. I don't see how this would be different versus a PCIe device? > If you connect USB input devices (keyboard and mouse) to a VM, that VM will effectively have control over your system. USB controllers use PCIe in order to function. It seems the primary difference between the two are which set of tools you go after to attck the system. The primary difference is that PCIe device attacks are less so in the wild (I do not know of a PCIe rubber ducky, but there is nothing stopping anyone from making it), and (depending on your system) involve more invasive physical access (USB is a physical port, but then again, Thunderport is effevtiely PCIe in a port: https://tidbits.com/2015/01/09/thunderstrike-proof-of-concept-attack-serious-but-limited/ https://tidbits.com/2015/01/09/thunderstrike-proof-of-concep... . There is an example attack against PCIe). As far an an IOMMU goes, that exists because PCIe uses DMA, so am IOMMU enforces boundaries so that a rogue PCIe device cannot do a DMA attack (here is one such exmaple: https://papers.put.as/papers/macosx/2006/ab_firewire_rux2k6-final.pdf https://papers.put.as/papers/macosx/2006/ab_firewire_rux2k6-... . I skimmed through it so I am not sure if it is entrely correct, but the theme of the attack applies). But an IOMMU is typically software based too, so one can attack that and the DMA controller. USB does not use DMA.
kop316 6y ago
>The Librem 5 does not even support software encryption and no progress has been made toward adding even LUKS encryption. OSK-SDL has been ported to the Librem 5 to the best of my knowledge (Source: talking to the actual dev working on it). > The Librem 5 lacks a secure element for any hardware binding on the encryption and so would be entirely dependent on software-only encryption. You do know it has a smartcard port right? That would be the whole point of having the smartcard: hardware binding encryption! Also see this: https://news.ycombinator.com/item?id=26773309 https://news.ycombinator.com/item?id=26773309 > Current releases of the Librem 5 have been plagued by thermal throttling issues and poor battery life which in some cases has clocked in at less than 1 hour at idle. Actual citation needed please, as this contradicts you: https://puri.sm/posts/librem-5-4500mah-battery-upgrade/ https://puri.sm/posts/librem-5-4500mah-battery-upgrade/ > This renders the firmware unupdateable without shorting a connection. That is simply incorrect: https://source.puri.sm/Librem5/redpine-firmware-nonfree https://source.puri.sm/Librem5/redpine-firmware-nonfree https://source.puri.sm/Librem5/firmware-tps6598x-nonfree https://source.puri.sm/Librem5/firmware-tps6598x-nonfree Note how the update procedure doesn't call for "shorting a connection". > Although the modems and radios are not attached to the host via DMA, they rely on USB for isolation, which simply shifts the trust from the kernel driver to the kernel USB stack, and USB was never designed with distrusting the device plugged into it in mind unlike SMMU/IOMMU, which is specifically designed to mitigate unconstrained DMA. Do you have a citation for this beyond a repository that says: "Something I should mention off the bat right now is that this repository is a rough draft. Much of the information in it is very work-in-progress, and some of it needs to be looked at." Being that off the top of my head I am able to contradict the most of your statements (with actual citations), I am skeptical of your claims, as laptops and other portable devices have to worry about rogue USB devices too, and this has been a known issue for over a decade. It seems almost all your comment is either 1) out of date (And the last commit to the repository you posted to was 11 Feb 2020) or 2) flat out wrong. tl;dr Did you do any real research on this topic?
- atat7024 6y ago
  tl;dr No, I literally said it was from a URL, and provided it...and I'm supposed to trust your info?
fsflover 6y ago
> In the event a vulnerability is discovered in the modems or radios, the firmware cannot be updated without physically dismantling the phone. But wouldn't it make the phone more secure, since no malware can update the firmware without your knowledge? (Although it's just not true as kop316 showed). > Current releases of the Librem 5 have been plagued by thermal throttling issues and poor battery life which in some cases has clocked in at less than 1 hour at idle. This was true about a year ago. Current state is 10-12 hours battery life without suspend. No thermal throttling issues anymore. https://source.puri.sm/Librem5/community-wiki/-/wikis/Frequently-Asked-Questions#21-how-long-will-be-the-battery-life-of-the-librem-5-evergreen https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque... > The Librem 5 does not even support software encryption Yes, it does: https://puri.sm/posts/sneak-peek-of-the-next-pureos-release-on-the-librem-5/ https://puri.sm/posts/sneak-peek-of-the-next-pureos-release-.... > The Librem 5 lacks a secure element for any hardware binding on the encryption and so would be entirely dependent on software-only encryption. Not true, it has a smartcard: https://puri.sm/posts/your-own-personal-enclave-the-smart-card-reader-on-the-librem-5/ https://puri.sm/posts/your-own-personal-enclave-the-smart-ca.... > uses the same security model as the desktop stack Yes, this may be a problem. However, you do not have to use PureOS. You can install anything you like on this phone. Concerning the USB isolation, you are probably right. How other phones deal with it? Couldn't you simply avoid connecting it to untrusted hosts?
- kop316 6y ago
  > But wouldn't it make the phone more secure, since no malware can update the firmware without your knowledge? No not really. Look up the boot ROM vulnerability on the Nintendo Switch. I'm sure Nintendo wishes they could update that.
  - fsflover 6y ago
    I am not saying that total lack of updates is more secure. I am saying that special actions required for the update can make it more secure.
    - kop316 6y ago
seba_dos1 6y ago
That's a massively inaccurate comment. > This renders the firmware unupdateable without shorting a connection. That's incorrect, the firmware can be updated by the user without having to modify the hardware. > the firmware cannot be updated without physically dismantling the phone Not true. > Firmware initialization is also no longer under the control of the host operating system because the initialization is carried out from outside the OS: changing or updating software on the host will not address these design defects. The OS can choose to not use the firmware stored on flash and load it directly from rootfs instead. postmarketOS does that already for WiFi firmware, for instance. Compiling u-boot that doesn't use the SPI flash for DDR blob is trivial as well. The point of having the flash is for the OS to not have to touch it, but nothing prevents the user from touching it if they really want, not even "having to short a connection". > Current releases of the Librem 5 have been plagued by thermal throttling issues and poor battery life which in some cases has clocked in at less than 1 hour at idle. That "current" means "fixed more than a year ago with software updates". > The Librem 5 does not even support software encryption and no progress has been made toward adding even LUKS encryption. Not true, LUKS works fine with PureOS Byzantium for months now. > The Librem 5 lacks a secure element for any hardware binding on the encryption and so would be entirely dependent on software-only encryption. There's a GPG smart card reader next to the battery compartment. > which may be mildly out of date ...as seen above. Don't trust any information about the Librem 5 coming from GrapheneOS developers, their reaction to pointing out their mistakes is to block the person that corrects them ;)
- kop316 6y ago
  Is this person a Graphene OS dev? I couldn't confirm that (from a cursory search), but if so, this massively undermines my confidence in using it on my Pixel.
  - seba_dos1 6y ago
    The person who wrote the comment I replied to? I don't think so, they just copy'n'pasted and linked to a page written by a GrapheneOS dev. However, I have some history of communication with GOS devs on Twitter trying to correct their mistakes and they always confidently repeat their misconceptions despite of clearly not knowing what they're talking about and it ends up with "I'm not lying, you're lying" and me getting blocked, so... (granted, I'm probably not the best in non-violent communication, but they could at least try to do some research anyway ;))

qchris 6y ago

Thanks for the info, I hadn't heard about the USB isolation architecture issue. I'm not sure about the status of LUKS on PureOS, but I know that Mobian supports it and there is a supported build of Mobian for the Librem 5. First-hand, I've encrypted my Pinephone image, but don't have a Librem 5 so can't independently confirm that it actually includes that during the eMMC flashing process, although I don't have a reason to believe elsewise. Not sure if it's bad practice to share, but then what options do you use? If Debian's security model isn't enough, do you roll your own Linux base from something else instead? What kind of hardware is there as an alternative?

kop316 6y ago
Considering most of his other post is factually incorrect and/or out of date, I am skeptical of the claim to be frank.
- atat7024 6y ago
  "You're wrong!" I can play that game, too!
  - kop316 6y ago
    Skeptical != wrong https://www.merriam-webster.com/dictionary/skepticism https://www.merriam-webster.com/dictionary/skepticism https://www.merriam-webster.com/dictionary/wrong https://www.merriam-webster.com/dictionary/wrong If there are factual in accuracies with my claims, I am happy to be proven wrong. That's how I learn! I just need proper citations.
- fsflover 6y ago
  Are you skeptical about bad security of USB? Here you go: https://www.qubes-os.org/doc/device-handling-security/#usb-security https://www.qubes-os.org/doc/device-handling-security/#usb-s....
  - kop316 6y ago
    I'm skeptical of that person's claims, primarily because the document the individual sourced as "fact" was riddled with factual errors. I don't know enough about USB security to make a judgement one way or another. Thank you for this source, I'll check it out!
    - kop316 6y ago
      So in reading that overview, the same attacks that would apply to USB apply PCIe: > The connection of an untrusted USB device to dom0 is a security risk since the device can attack an arbitrary USB driver (which are included in the linux kernel), exploit bugs during partition-table-parsing or simply pretend to be a keyboard. This would be the same for any PCIe device. PCIe does not have any cryptographic authentication scheme that I am aware of, and PCIe device drivers are likewise in the linux kernel. > The whole USB stack is put to work to parse the data presented by the USB device in order to determine if it is a USB mass storage device, to read its configuration, etc. This happens even if the drive is then assigned and mounted in another qube. I don't see how this would be different versus a PCIe device? > If you connect USB input devices (keyboard and mouse) to a VM, that VM will effectively have control over your system. USB controllers use PCIe in order to function. It seems the primary difference between the two are which set of tools you go after to attck the system. The primary difference is that PCIe device attacks are less so in the wild (I do not know of a PCIe rubber ducky, but there is nothing stopping anyone from making it), and (depending on your system) involve more invasive physical access (USB is a physical port, but then again, Thunderport is effevtiely PCIe in a port: https://tidbits.com/2015/01/09/thunderstrike-proof-of-concept-attack-serious-but-limited/ https://tidbits.com/2015/01/09/thunderstrike-proof-of-concep... . There is an example attack against PCIe). As far an an IOMMU goes, that exists because PCIe uses DMA, so am IOMMU enforces boundaries so that a rogue PCIe device cannot do a DMA attack (here is one such exmaple: https://papers.put.as/papers/macosx/2006/ab_firewire_rux2k6-final.pdf https://papers.put.as/papers/macosx/2006/ab_firewire_rux2k6-... . I skimmed through it so I am not sure if it is entrely correct, but the theme of the attack applies). But an IOMMU is typically software based too, so one can attack that and the DMA controller. USB does not use DMA.

kop316 6y ago

>The Librem 5 does not even support software encryption and no progress has been made toward adding even LUKS encryption. OSK-SDL has been ported to the Librem 5 to the best of my knowledge (Source: talking to the actual dev working on it). > The Librem 5 lacks a secure element for any hardware binding on the encryption and so would be entirely dependent on software-only encryption. You do know it has a smartcard port right? That would be the whole point of having the smartcard: hardware binding encryption! Also see this: https://news.ycombinator.com/item?id=26773309 https://news.ycombinator.com/item?id=26773309 > Current releases of the Librem 5 have been plagued by thermal throttling issues and poor battery life which in some cases has clocked in at less than 1 hour at idle. Actual citation needed please, as this contradicts you: https://puri.sm/posts/librem-5-4500mah-battery-upgrade/ https://puri.sm/posts/librem-5-4500mah-battery-upgrade/ > This renders the firmware unupdateable without shorting a connection. That is simply incorrect: https://source.puri.sm/Librem5/redpine-firmware-nonfree https://source.puri.sm/Librem5/redpine-firmware-nonfree https://source.puri.sm/Librem5/firmware-tps6598x-nonfree https://source.puri.sm/Librem5/firmware-tps6598x-nonfree Note how the update procedure doesn't call for "shorting a connection". > Although the modems and radios are not attached to the host via DMA, they rely on USB for isolation, which simply shifts the trust from the kernel driver to the kernel USB stack, and USB was never designed with distrusting the device plugged into it in mind unlike SMMU/IOMMU, which is specifically designed to mitigate unconstrained DMA. Do you have a citation for this beyond a repository that says: "Something I should mention off the bat right now is that this repository is a rough draft. Much of the information in it is very work-in-progress, and some of it needs to be looked at." Being that off the top of my head I am able to contradict the most of your statements (with actual citations), I am skeptical of your claims, as laptops and other portable devices have to worry about rogue USB devices too, and this has been a known issue for over a decade. It seems almost all your comment is either 1) out of date (And the last commit to the repository you posted to was 11 Feb 2020) or 2) flat out wrong. tl;dr Did you do any real research on this topic?

atat7024 6y ago
tl;dr No, I literally said it was from a URL, and provided it...and I'm supposed to trust your info?

fsflover 6y ago

> In the event a vulnerability is discovered in the modems or radios, the firmware cannot be updated without physically dismantling the phone. But wouldn't it make the phone more secure, since no malware can update the firmware without your knowledge? (Although it's just not true as kop316 showed). > Current releases of the Librem 5 have been plagued by thermal throttling issues and poor battery life which in some cases has clocked in at less than 1 hour at idle. This was true about a year ago. Current state is 10-12 hours battery life without suspend. No thermal throttling issues anymore. https://source.puri.sm/Librem5/community-wiki/-/wikis/Frequently-Asked-Questions#21-how-long-will-be-the-battery-life-of-the-librem-5-evergreen https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque... > The Librem 5 does not even support software encryption Yes, it does: https://puri.sm/posts/sneak-peek-of-the-next-pureos-release-on-the-librem-5/ https://puri.sm/posts/sneak-peek-of-the-next-pureos-release-.... > The Librem 5 lacks a secure element for any hardware binding on the encryption and so would be entirely dependent on software-only encryption. Not true, it has a smartcard: https://puri.sm/posts/your-own-personal-enclave-the-smart-card-reader-on-the-librem-5/ https://puri.sm/posts/your-own-personal-enclave-the-smart-ca.... > uses the same security model as the desktop stack Yes, this may be a problem. However, you do not have to use PureOS. You can install anything you like on this phone. Concerning the USB isolation, you are probably right. How other phones deal with it? Couldn't you simply avoid connecting it to untrusted hosts?

kop316 6y ago
> But wouldn't it make the phone more secure, since no malware can update the firmware without your knowledge? No not really. Look up the boot ROM vulnerability on the Nintendo Switch. I'm sure Nintendo wishes they could update that.
- fsflover 6y ago
  I am not saying that total lack of updates is more secure. I am saying that special actions required for the update can make it more secure.
  - kop316 6y ago

seba_dos1 6y ago

That's a massively inaccurate comment. > This renders the firmware unupdateable without shorting a connection. That's incorrect, the firmware can be updated by the user without having to modify the hardware. > the firmware cannot be updated without physically dismantling the phone Not true. > Firmware initialization is also no longer under the control of the host operating system because the initialization is carried out from outside the OS: changing or updating software on the host will not address these design defects. The OS can choose to not use the firmware stored on flash and load it directly from rootfs instead. postmarketOS does that already for WiFi firmware, for instance. Compiling u-boot that doesn't use the SPI flash for DDR blob is trivial as well. The point of having the flash is for the OS to not have to touch it, but nothing prevents the user from touching it if they really want, not even "having to short a connection". > Current releases of the Librem 5 have been plagued by thermal throttling issues and poor battery life which in some cases has clocked in at less than 1 hour at idle. That "current" means "fixed more than a year ago with software updates". > The Librem 5 does not even support software encryption and no progress has been made toward adding even LUKS encryption. Not true, LUKS works fine with PureOS Byzantium for months now. > The Librem 5 lacks a secure element for any hardware binding on the encryption and so would be entirely dependent on software-only encryption. There's a GPG smart card reader next to the battery compartment. > which may be mildly out of date ...as seen above. Don't trust any information about the Librem 5 coming from GrapheneOS developers, their reaction to pointing out their mistakes is to block the person that corrects them ;)

kop316 6y ago
Is this person a Graphene OS dev? I couldn't confirm that (from a cursory search), but if so, this massively undermines my confidence in using it on my Pixel.
- seba_dos1 6y ago
  The person who wrote the comment I replied to? I don't think so, they just copy'n'pasted and linked to a page written by a GrapheneOS dev. However, I have some history of communication with GOS devs on Twitter trying to correct their mistakes and they always confidently repeat their misconceptions despite of clearly not knowing what they're talking about and it ends up with "I'm not lying, you're lying" and me getting blocked, so... (granted, I'm probably not the best in non-violent communication, but they could at least try to do some research anyway ;))