Would you mind elaborating on that? My understanding is from a verification point of view, the Librem 5 is functionally at the absolute top-tier in terms of OpSec concerns, with everything from the bootloader up being open and customized, full disk encryption available, and the only binary blobs (I think on the modem?) being completely sandboxed. Are there additional concerns, and what kind of solutions do they currently use that do meet those needs?
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.
> 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.
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.
> 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 ;)
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 ;))
> (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.
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.
First time was with someone behind the official GrapheneOS twitter account, and second time was with Daniel Micay, both times about the hardware supposedly preventing the ability to update the firmware even when running alternative software.
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.
If you install an alternative distro on the Librem 5, you're already using a different kernel and bootloader; exactly like on a PC. This is not some locked down Android device where that could be considered rocket science.
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?
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.
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-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.
>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://hackertimes.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.
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.
Anyway, to actually answer your question, if you need a source that the Librem doesn't have an IOMMU, then frankly you're out of your depth for this conversation.
...are you going to address, you know, the rest of your comment being factually incorrect?
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.
considering doing ctrl + f "atat7024" proves otherwise, you are simply not worth replying to anymore, seeing as how you cannot conduct basic research or you are willing spreading misinformation.
The way you cited this URL indicated you believe it to be fact.
https://hackertimes.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!
