PinePhone Misconceptions(pine64.org) |
PinePhone Misconceptions(pine64.org) |
If the user encrypts the data before sending it, whether the 4G modem/WiFi/BT are closed or not, they will see just noise.
This is why the terminology used by the BSD community is much more realistic and pragmatic.
http://www.gnu.org/distros/common-distros.html#BSD — «In BSD parlance, the term “blob” means something else: a nonfree driver.»
http://www.openbsd.org/lyrics.html#39 — «Blobs are vendor-compiled binary drivers without any source code.»
http://web.archive.org/web/20060603230017/http://kerneltrap.... — «Of course, also note that we don't want to become Hermes (the architecture of the Lucent/Prism/Symbol chip) assembly language programmers... we have more than enough to do. Just a specific example. Please, people, don't load us up with more tasks ;)» (NB: Theo's talking about the wi(4) firmware, see http://mdoc.su/-/wi.4 .)
I'm pretty sure that both of them could completely compromise you
One question: does anyone know where encryption occurs for 4G and Bluetooth voice for example? Is audio going to a BT headset encrypted inside the BT chip? Is audio going to the 4G network encrypted inside the modem?
Edit: Thanks for your replies.
The point of the pinephone post here is that you're basically treating the entire modem as untrusted and part of the internet rather than part of your device, which is the correct approach.
The point is: we can't have a 100% fully open and auditable system, both in HW and SW, so they built a fence to separate the trusted hardware in which we work with our data and the untrusted but necessary part where our data can't enter before being encrypted.
It's a huge effort, which brings us one more time on the importance of having full open hardware/firmware/software. I wonder if current technology would allow crowfunding the creation of fully open chipsets. Nothing immediate, just one damn chip at a time: networking today, storage controllers in two years, graphics in 5, etc.
However, there is the risk that compromised cellular or WiFi modules could defeat isolation, and fsck with the AP etc.
But if that's a concern, you can turn them off, and use tethered cellular or WiFi. And if you really 100% don't trust the USB bus, you can tether through Ethernet.
Even then, it'd actually be Ethernet via USB-C. But perhaps the additional transport layer would increase isolation.
I'd love to see arguments why that makes sense, or doesn't.
That's actually pretty impressive, isn't it? I was under the impression that RAM setup was a mess.
And the way it works with these chips it's a pain to support more than one board layout with more than one model of chips, but that's more a supply chain and SKU explosion issue.
https://redmine.replicant.us/projects/replicant/wiki/Pinepho...
My actual point is: You don't need special camera firmware to do this.
What you do need special (or open enough) firmware for is stuff like long exposures - the inability of which highly frustrated me on the phones, especially from Sony, I have owned so far. Doing weird stuff with the camera will probably be quite fun, but then again I don't believe the actual camera device will be that good.
RE cellular modems, there are some things worth noting. First, they are a huge privacy hole. It doesn't matter if they run open or closed firmware, the real adversary is the cell provider's hardware. Second, interoperability is a real problem. There would be large consequences if enough improperly configured cellular modems ended up in the wild.
Edit: Another point here. Open firmware does guarantee security. It is unlikely that whatever distro you end up running on your pine phone will be nearly as secure as iOS or Android. Of course privacy is a different story.
If the modem is on, the carrier can figure out your location relatively precisely from your transmissions, even if GPS were disabled.
So the real loss is that you can't use the device for navigation/mapping without turning on the modem.
Right?
At least this can be resolved by using an external receiver.
Virtual UART drivers for every phone since 3G HSDPA creates GPS NMEA ports on your PC and it spits it garbage when it feels like doing.
Ask them on twitter @thepine64 Though how the SOC is wired up inside may beyond their scope or the dreaded NDA from the SOC supplier.
Looks like GNSS is directly on the modem chip.
Has anyone actually gotten one of these yet? Any critical impressions? Could I actually rely on it as a phone?
First mention of Linux I’ve seen wrt modem firmware. Interesting!
It also uses an android bootloader and partition layout, and can support adb connections.
Perhaps the GPS issue can be solved by disconnecting the GPS antenna using a kill switch.
> The judge called Fairfield’s participation in the scheme “aggravated” because of the significant amount of money laundered, the use of his expertise and the four-year stretch of illegal activity.
In contrast, anyone (including law enforcement officials) can buy a PinePhone, and I doubt Pine64 is laundering money. It is unlikely for Pine64 to be prosecuted the way Phantom Secure was.
I’m not sure who would be surprised by this, I feel like anyone that cares this much would be paying enough attention to know what’s going on.
Encryption of IP traffic happens on the open system, so no problem there.
If you'd like to complain about encryption of voice calls happening on the closed modem, I have some bad news. It wouldn't matter if it was open or closed, since the network it negotiates keys with is also compromised.
The only problem remaining, on this particular device, is direct connection of physical sensors (microphone, GPS, etc) directly to the modem. This is solved by physical switches (or hardware switches controlled from the open system) between the sensor and the modem.
The only exception I see now is the GPS, which is embedded into the modem. If they solve that, I'm buying the phone.
You can't use cellular or WiFi without being geolocated. But as long as the modems are securely isolated from the open system, geolocation information can't pollute your communications. There's obviously the same geolocation issue with broadband.
Also, that isolation prevents compromised modems from compromising the open system, and the accessing data, compromising end-to-end encryption, and so on.
Both are aspects of modems being "treated as compromised/hostile".
is that even the case of the microphone? My understanding was that - independently of the possibility to turn the microphone and modem off with kill switches - all audio data to the modem comes via I2S from the SoC anyways, i.e. that the microphone is NOT directly connected to the modem but to the SoC (possibly via a separate audio codec Chip) and that the SoC serves the modem via I2S whatever audio data the user pleases (whether that be from the microphone or whatever else).
So does make open source modems rare, liability exposure of legal fallouts make for some muddy waters.
The PinePhone appears to use a similar approach here. The modem's only job is to provide a data connection, and ideally everything sent through that connection is encrypted in such a way that even if the modem wanted to snoop, it would be unable to do so. All it sees is encrypted noise, with the OS and application doing everything they can to keep it that way. The additional hardware isolation helps to ensure that even if the modem is compromised in some way by an attacker (difficult, but theoretically not impossible) it has very limited access to the rest of the phone, and would hopefully not be able to do very much damage. This is in stark contrast to most of the rest of the mobile industry today, which happily integrates the modem into the rest of the memory space, and would be at far greater risk should a modem exploit be discovered.
None of this is perfect, of course. In a perfect and ideal world, a FOSS modem would exist at scale, and the PinePhone would use that and all of the firmware would be open source. But the practical reality is that, at scale, a closed blob for the modem is required; no alternative exists that's cost effective enough to bring to market. So, the phone is designed to give that blob just as little trust as possible while still making the connection work. I think that's a perfectly fair trade.
Is that still the case? I though that most phones now isolate modems via some flavor of USB with IOMMU.
And indeed, that phones now isolate modems better than Intel and AMD machines isolate USB devices. There's IOMMU, but only some software actually uses it, such as Qubes.
We have two devices coming to market that take ideologically different approaches to choose from: the PinePhone (pragmatic compromise) and the Librem 5 (no compromise). So just pick where on the libre spectrum you want to live and enjoy 2020... it should be a fun year!
Basically the post says that the PinePhone mobile phone is, with the exception of the "mobile phone" part, a completely open source mobile phone.
It's just a funny way to write the post. If you remove the mobile phone part it's not a mobile phone. It's like saying a cake is, with the exception of the cake part, completely vegan.
This gets us into the situation we see today: even if you have a Phone that you can run your own firmware on it, it has a lifetime because the vendor has little financial intentive to do so.
Even the most open Android Phones (Pixels) have about a 3 year lifetime:
https://support.google.com/nexus/answer/4457705
On an iPhone, you are completely at the mercy of Apple for updates (for which they have a much better track record than Android).
Meanwhile, my Thinkpad x200 was released in 2008 and continues to be a supported just fine, with no end in sight. I hate to say, in contrast to even my Novena, is much better, as my Novena sits in my desk because it does not run mainline Linux, and I can't even get it to run properly on an updated Linux 4.4 Kernel that I tried to compile (due to no support).
So the Pinephone (and Librem 5) shooting to ensure that they can run unmodified Mainline Linux is a huge win for openness and longetivity in a Phone.
Hm, isn't it theoretically possible to use the checkm8 exploit to boot your own code? Is the problem just that writing your own OS for the iPhone is difficult, or is there anything actually blocking you once you have code execution in the boot ROM?
The vast majority of laptops have closed-source BIOS. The vast majority of laptops have components with closed-source firmware with access to RAM (Intel ME comes to mind), which includes BIOS (because it keeps running after boot).
Also, only modern laptops have IO-MMUs to prevent PCI-Express devices from accessing the RAM directly. (PinePhone simply doesn't use PCI-E)
And I don't think there is /any/ x86 laptop on which we know how to do DRAM initialization without closed-source blobs.
Pre-SandyBridge 2009 era stuff?
Both Phones have to load firmware into the Modem and WiFi/BT.
In theory you can change the modem/wifi in the Librem, that may be more "open" but you pay for it in size.
In the US, hams are prohibited from employing encryption with the single exception for control coms with amateur space-based radios. With the proliferation of digital modes, the encryption rule is increasingly being challenged and it will be interesting to see where this goes in the future.
That's the point of the article: being capable of running code on main CPU is but the first step, drivers and firmware for all the other parts are far more problematic.
With the PinePhone (and also the Librem 5) the modem and SoC are physically seperate so the communication between those two components can be inspected and controlled.
But iOS devices don't have the cellular modem in the SoC.
And neither does the latest from Qualcomm with 5G, which I gather will go in at least high-end phones.
> USB, i2c and SPI are effective measures against malicious hardware taking control of the system bus and sucking data from peripherals.
BTW, it's not I2C, but I2S that PinePhone has as one of these interfaces, but that makes little difference — it's still hardly something over which you can DMA. (I'd be more concerned about USB, however.)
---
The problem with GNU and Stallman's logic is how arbitrary the line is drawn — if the hardware has proprietary logic like a microwave, that's fine; but if it allows to be upgraded by the user, it's suddenly not fine. The difference between one of these devices having some ROM, or letting the host upload the firmware, is minuscule. In fact, if you're concerned about hardware compromise, it would actually be better if the hardware is ROM-less, and you're the one who is uploading that binary blob into a device, because then they can't just intercept your laptop on being shipped from the vendor by simply installing a compromised memory chip with compromised firmware. (Of course, this is rather trivial example, because if they do intercept hardware, then they might as well just swap the whole device even if it's ROM-less, but then they gotta fit more stuff into a smaller space. And, of course, the whole thing being OSS is the best option, but this is just a threat-model analysis here — it's slightly more secure to upload the firmware yourself than have it ship with the hardware.)
Right, but hardware compromised has never been the focus of GNU and Stallman. Saying the distinction is arbitrary from that POV is rather missing the point.
I mean, let's go back to that quote about assembler from Theo:
http://web.archive.org/web/20060603230017/http://kerneltrap.... — «Of course, also note that we don't want to become Hermes (the architecture of the Lucent/Prism/Symbol chip) assembly language programmers... we have more than enough to do. Just a specific example. Please, people, don't load us up with more tasks ;)» (NB: Theo's talking about the wi(4) firmware, see http://mdoc.su/-/wi.4 .)
DDG for "Stallman microwave" returns this page and this quote:
http://stallman.org/stallman-computing.html — «As for microwave ovens and other appliances, if updating software is not a normal part of use of the device, then it is not a computer.»
Now, what does that firmware for wi(4) actually even does? How's it different from the hardware itself? What sort of language is it written in? I'm mean, I'm a kernel developer here, I've hacked drivers and subsystems because they weren't working properly, but are you seriously going to argue here that actually updating this firmware is any more common than updating the software of the microwave?
I mean, let's take a look and find out. NetBSD appears to have it all in a single dir over at http://bxr.su/n/sys/dev/microcode/wi/ — clicking on any individual file, then the CVSweb link, reveals that it's been committed 15 to 17 years ago and not once updated (apart from the whitespace in the .h header file). Searching for these files in OpenBSD reveals the same situation — http://bxr.su/o/sys/dev/microcode/symbol/ .
So, basically, the manufacturer decided to save a few cents by omitting a ROM component on their cards; requiring you to bootstrap the device by giving it its firmware on each boot. How's that any different from the situation where the ROM chip is fixed from the factory? As a user and kernel developer, I don't really see a difference. Would it be nice if the firmware is OSS? I mean, sure, but it's written in a proprietary language anyways, for proprietary hardware, and it's really much more part of the hardware than it is of the software or the OS, and there's better battles to fight here than getting this sort of useless thing FLOSS'ed.
In fact, those 12-hour clocks on most microwaves are really annoying, and there's never an option to fix it. It should be possible to get the source code for all those microwaves to fix them to use 24-h time; I'd much rather campaign for that than for making wi(4)'s firmware OSS.
CPU -> LTE Modem || DMZ || Cellphone Provider
CPU || DMZ || LTE Modem -> Cellphone Provider
Remember that in the first model, and in most typical phones, the LTE Modem have above root access to the CPU through DMA. The exception is some more modern devices like the iPhone, which give the modem a specific sandbox device to DMA into that's not the actual processor.
It'd be nice if the PinePhone supported this.