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://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.
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://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!
In theory this makes tons of sense but despite microbenchmarks your expensive phone is still a kind of mediocre little computer and for optimal usage needs more ports a display, keyboard, pointing device, and battery.
Basically it needs everything but the motherboard/cpu/ram meaning you need a $500 peripheral to turn your awesome $1000 dollar phone into a merely OK computer.
If you really want to save money you probably have a $400 laptop and a $100 phone. If you have money to spend a $1000 phone AND a $1500 laptop will be a nicer experience.
With support for arm software better than ever before and better hardware available cheaper than ever before its better than it has ever been for this idea but it would still be a compromise that you have to convince your customer they ought to both pay substantially for and accept.
Not true in the Apple ecosystem. The Apple Silicon chips in recent iPhones can trounce desktop chips from a few years ago, and the next-gen iPhone should rival a high-spec desktop from today.
A high spec desktop from today has 32 3.7Ghz cores that 1 to 1 spank apple silicons 4 fast cores 32GB - 1TB of RAM and GBps of access up to TBs of storage or slower access to 10s of TB. It can use 1000W if need be and active cooling.
Claims that Apple is going to blow the rest of the market away usually revolve around
- Careful choice of chips usually involving only apple hardware running less than current generation hardware in thermally constrained situations
- Pretending that AMD doesn't exist
- Pretending that both Intel's slump in progress and Apple's progress are permanent unchangeable trajectories rather than the current status.
- Pretending that we can anticipate a fixed factor improvement over a given time based on changing power envelope. The just add power argument that suggests that future desktop chips will n times faster based on having n times the power and cooling an oversimplification an apple engineer is unlikely to make. You haven't made this one of course you think they will be able to blow away the 1000 watt desktop in 7 Watts. Which is more interesting yet.
- Pretending that a favorable microbenchmark chosen primary because it reflects desired reality rather than applicability proves not only anything about real world performance but everything.
The 2022 iphone still wouldn't make a great computer and the Apple atrix if it were to come to pass would still require you to buy hardware that is liable to be nearly as expensive to make and as bulky as a macbook for a worse experience. Why would a premium buyer want that?
Can you imagine Apple trying to make a laptop with a phone sticking out of it cool? Sliding it into something would be problematic for cooling. The sheer uncoolness is probably even more fatal than the performance.
Sorry if it sounds like I’m moving the goalpost but no. Apple, Android doesn’t matter. They are all trash.
The fact that I can’t remove the battery, and have the phone working when connected to external power makes every single phone (even those with user serviceable battery) garbage.
I don’t know of a single recent phone that works off of external power. Personally, I think this is enough to prohibit sale of a device.
What I expect when a device is connected to power is for it to
1. work off of external power directly
2. charge the battery to an optimal level (possibly 60 to 80 percent?) and STOP charging
I’d have thought this was the default way all electronics works. I know for a fact that my 2006 MacBook just worked if I remove the battery. Same with my random Asus N61JVx2 notebook computer as well.
FWIW, the Librem 5 can fully work with no battery (including the cellular modem and WiFi, which often don't work with no battery on other phones) as long as it's connected to a powerful enough USB-PD power source. You can also reconfigure the battery charger directly via its I2C interface: https://www.ti.com/lit/ds/symlink/bq25895.pdf
I believe the reason is typically because they want to make the design of chargers cheaper and the circuitry inside simpler and ergo cheaper as well. What you want has a slightly higher unit cost and in 99.99% of cases doesn't impact the users usage.
Laptops are designed to run off battery or power because this is how many people typically use laptops. They plug them in places where they use them for long periods of time whereas phones are virtually always charged for a short period of time often overnight and then carried around and used unplugged virtually all of the time.
I have found the best solution to be to acquire hardware with more than sufficient battery power so as to only worry about charging it every 2-3 days when I'm sleeping. Phones exist with up to 5AH of battery power.
> I believe the reason is typically because they want to make the design of chargers cheaper and the circuitry inside simpler and ergo cheaper as well. What you want has a slightly higher unit cost and in 99.99% of cases doesn't impact the users usage.
Makes sense but really given how much every company harps about going green... I don’t know whether a lot of people use their phones while charging but I think they do. At least I do.
You brought up a good point though. I should just get a phone with a huge battery. So no pixel and no iPhone.
The USB-C port doesn't provide enough power for the Wi-Fi radio to work, but ethernet (via USB-C hub) would work fine. Excluding that (major) use-case, the Pinephone works just fine using external power instead of the battery. Hell, for that matter, I'm tempted to find out if an external Wi-Fi dongle would work...
The cellular modem also doesn't work without battery on the PinePhone (it does on the Librem 5 though). It's not a matter of providing enough power - on the PinePhone (and many other phones as well) those things are powered straight from the battery, because to make it work otherwise you have to provide enough capacitance to handle big power spikes (which the Librem 5 does, as it's not meant to optimize for low price or thickness).
Is it an OS thing or a hardware thing? I like the idea of using something like postmarketOS to repurpose an old smartphone, but I agree for long term use the battery might not be a good idea (especially if the hardware tries to keep it at 100%).
I have now fried two different phone batteries trying this: basically I wanted to set up old phones as time lapse photo capture using open camera but the battery swells up and becomes a fire hazard in a few weeks/months.
Old phones seem like a really nice cheap high quality camera shame it doesn't work. Have you tried setting up something like a single board computer + usb cam?
Respectfully, ubuntu touch is a terrible OS. When people ask for convergence on a phone they want a normal desktop Linux OS not an Android knockoff that can run some X11 apps.
GTA01 and GTA02 had no way to connect external screen though, and even if they had it it wouldn't be pleasant at all - Glamo was even too weak to drive the internal VGA screen :) But yeah - I'm working on the Librem 5 now, but I remember making my first steps in Python on the Openmoko Neo Freerunner back in 2008 while starting to contribute to SHR and it still has a special place in my heart!
The Telegraph online is full of clickbait and articles worthy of a tabloid. There’s nothing broadsheet about it beyond the fonts/styling used and its historic reputation.
(In the interest of balance, The Guardian is shit too)
You can start by example, I might join after laws are changed, especially the one that if you are unfortunate, you can end up being labeled a sex offender for taking a leak.
What does this have to do with peeing? Peeing outside isn't a crime. Intentional nudity meant to surprise someone can still be sexual assault, these two are not mutually exclusive.
>>My wife has it happen like once a month at least
I'm in Asia, in a place with no laws. I won't beat a native person to death for this kind of thing, but if you're "peeing" in front of children, which I have seen multiple times from foreigners here, then get ready. If you're in a city, keep your fucking dick in your pants, just in case your around somebody like me that is shell shocked by too many experiences witnessing pathetic attempts at sexual assault, both "visual" and physical.
only one of the five vaccine-production plants listed in the EU contract with AstraZeneca was delivering vaccines to the EU.
The contract lists two factories in Britain, one in the Netherlands (Halix), one in Belgium. Another one in the United States is listed as a back-up supplier. Currently, only the plant in Belgium, run by Thermo Fisher Scientific, is producing shots for the EU.
The Commission has also started a procedure foreseen under the contract with AstraZeneca that could lead to legal action against the company.
