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/ma... which may be mildly out of date — but I doubt it.
tl;dr Wake me up when you have an IOMMU!
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/Freque...
> The Librem 5 does not even support software encryption
Yes, it does: 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-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?
No not really. Look up the boot ROM vulnerability on the Nintendo Switch. I'm sure Nintendo wishes they could update that.
I'm not sure if I agree or not to be honest. I think there's good things (like you said, make sure the user knows they are doing it), but I have never convinced myself it is absolutely superior.
EDIT: One example of why it may not be good. If there is friction to updating, it means less folks will update (or you have to now take special care to make it as easy to update as if the switch was not there).
But like I said, I'm not convinced one way or another. I think there's cases when it is true, but I lean to that being the exception, not the rule.
Some seriously forward thinking shit.
> 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 ;)
I couldn't confirm that (from a cursory search), but if so, this massively undermines my confidence in using it on my Pixel.
(granted, I'm probably not the best in non-violent communication, but they could at least try to do some research anyway ;))
> (granted, I'm probably not the best in non-violent communication, but they could at least try to do some research anyway ;))
Considering how badly incorrect the dev's page is, I agree. I gave them some credit since it was over a year old, but if they behave like that, it sounds like I need to reinstall LineageOS.
I wouldn't recommend this to anyone as a first choice.
Which is riddled with errors. Make a well cited annotation of the errors.
You say you addressed my comments "elsewhere" https://news.ycombinator.com/item?id=26783664
I ask you where.
Your response is a deflection: https://news.ycombinator.com/item?id=26784172
My interaction with you has only undermined my confidence in GrapheneOS (especially considering seba_dos1's perspective, and he is a person I have worked with and I trust his judgement). I have no idea why you think I would listen to you about LineageOS.
In reality, the only thing that prevents the firmware from being upgraded is the default software not implementing such features (because PureOS does not and will not distribute non-free software or firmware). A user who wants to do that can reflash everything without modifying the hardware in any way or even opening the case. Both WiFi flash and the M4 core-based solution described in https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd... can be bypassed completely to load the firmware from rootfs just by using a different kernel and bootloader, and disabling SPI flash read-only protection is a single line of code change in the device tree.
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?
Thank you for this source, I'll check it out!
> 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-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-... . 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.
Some of that outdated post's problems could be rectified. Some (important!) ones cannot.
As stated elsewhere: wake me up when you have an IOMMU.
I can play that game, too!
https://www.merriam-webster.com/dictionary/skepticism
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.
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
> 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/
> 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/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?
I am saying the rest of your document you cited was riddled with errors that I could show was wrong off hand (with citations!), so any claims you make that I don't know is right, I treat with skepticism.
I'm unconvinced that you have actually looked through the source of the Librem 5, considering you didn't know it supported encryption! Hell, did you look at their product page? You can see that it has a smartcard on their product page! And yet you claimed it doesn't have "hardware backed encryption".
So either you are a) completely unaware of how to do basic research and citations or b) willfully spreading misinformation.
Just have elsewhere.
All I can do is point.
https://news.ycombinator.com/item?id=26772189 When you make a claim like that, which I assumed meant your company did some sort of baseline research for this claim. Your reply directly contradicts that statement since your citation is riddled with errors.
I actually sourced all of my info (except for the OSK-SDL one...but I don't exactly know how to source a conversation between two people, so you'll have to trust me on that one. Alternatively, you are welcome to do your own research to counter my claim!). Are there problems with my citations? In the scientific community, this is why we cite sources. I don't have to trust the primary author when their sources are cited!