[squarefoot]

What most critics miss about its hardware is that the few closed subsystems have no access to system memory and storage. It is very different from say a ME module into a CPU, or a closed card stuck into the same bus with the disk controller, which is the case of just every "open" laptop out there. USB, i2c and SPI are effective measures against malicious hardware taking control of the system bus and sucking data from peripherals. Even in the unlikely (but technically possible) scenario in which some chips loaded with malicious firmware attempt to sniff the i2c bus, they will be fed data that has been already encrypted on a system memory, bus and storage they have no access to.

If the user encrypts the data before sending it, whether the 4G modem/WiFi/BT are closed or not, they will see just noise.

[cnst]

This is one good reason why the GNU crowd is doing more harm than good by labelling both the firmware as well as device drivers as "blobs" without taking any time to elaborate that one is much worse than the other.

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 .)

[OrgNet]

> the firmware as well as device drivers as "blobs"

I'm pretty sure that both of them could completely compromise you

[cnst]

Did you just miss the original comment?

> 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.)

[icebraining]

> In fact, if you're concerned about hardware compromise

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.

[cnst]

The distinction is still arbitrary even if you omit the hardware compromise aspect.

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.

[zzo38computer]

If it is compromised then they can install ROM and use that instead of the uploaded firmware (possibly using a checksum to make it more difficult to detect).

[throwaway41597]

The PinePhone looks compelling indeed.

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.

[RL_Quine]

There's not really any meaningful encryption in LTE in the real world, that there is is vulnerable to all sorts of nasty downgrade attacks. You're better forgetting there is any and assuming that it's all in cleartext. Any there is will be deciphered on the radio hardware and then send in the clear to the main processor. This is how it always works.

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.

[squarefoot]

This is possible, although if the user has control over the "trusted" part of the system, nothing prevents the data to be encrypted before leaving it. That is, suppose we know the radio chip contains the encryption code, but also some suspicious closed firmware we cannot examine; since we can't trust that chipset, we could add one more encryption layer on the data before it reaches the untrusted chipset, so that any potentially malicious firmware would see essentially random noise. Of course the other end must employ the same decryption scheme, which is not immediate for sure, but still doable and would make extremely difficult for anyone to snoop our data.

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.

[kop316]

I would assume each would happen inside the BT chip and inside the modem, respectively.

[mirimir]

I pretty much agree.

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.