yawnn.. ubuntu touch had convergence 5 yeas ago, nobody cared
Convergence has been held back by UX and UX alone.
It's the single most-requested feature at my bespoke secure technology firm.
I'm curious now, is your firm going to order a bunch of Librem 5 phones?
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!
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 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.
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.
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?
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!
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.
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.
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.
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.
Why can’t new devices do this?
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.
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.
> 2. charge the battery to an optimal level (possibly 60 to 80 percent?) and STOP charging
Asus Rog phone 3 & 5 actually have this bypass charging, and to restrict charging level(but can only set between 80%-100%).
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.
I still use it every day, since it has my two-factor auth credentials (in GPG); although I transferred my SIM to a PinePhone last Christmas :)