Librem 5 Smartphone Now Plans To Ship With KDE Plasma

[Uqbar]

There is no open baseband that you can use outside a test lab. And even if there was one you could not use your own builds legally because of regulations which require you to certify the firmware. And even if you could solve that, baseband has always the major flaw that you are track-able and there is no end-to-end encryption, there is simply no way around that no matter what modem you use.
However, you can disable the baseband completely and just use anonymous WIFI since the librem 5 phone stack will use matrix.
The included baseband and wifi will probably have proprietary firmware but it is completely separated from the device and only connected via USB without memory access.
This is the best solution I have seen so far apart from no phone at all, even feature phones.

Do you think WiFi doesn't need a blob?

[DrYak]

Do you think WiFi doesn't need a blob?

Wifi as a *standard* doesn't require a blob.

It works on frequencies - like 2.4 GHz - which happen to be free for everyone to use.
That's why nearly every quickly designed publicly available wireless standard uses 2.4 Ghz (Wifi, Bluetooth, Logitech's wireless-USB-like, etc.)
That's why even your micro-even work at 2.4 GHz.

If in your garage you manage to build your very own device that only speaks at 2.4Ghz and doesn't go beyond the legal accepted output level, you could take your home built device on the street and start connecting to the access points you want (I'm over simplifying, but yes).

No problem.

(the only actual minor nitpicking comes from the details. It's not EXACTLY the same range around 2.4Ghz that is free in all country. There isn't a perfect over lap of frequencies between all.
In some countries, frequency at the limit are freely accessible, whereas in other countries the exact same frequency requires a license.
The usual solution used by lots of provider is building hardware that can actually use ALL these frequencies, but then have some closed source limitation (either a firmware or a blob driver) that block you access to some frequencies if they happen to not be allowed in the peculiar country.
That's why some manufacturer end up with BLOB that they categorically refuse to open.
But your "garage made wifi" would be allowed as long as you limit to the allowed frequencies)

Cell modem, on the other hand DOES require a blob BECAUSE of the standard.

Cell modem, on the other hand use a different set of frequencies. THOSE frequencies require a license to be used.
Unless you actually happen to be a license holder, you CANNOT build your very own cell modem and take it out in the street. That would be completely illegal.
Only entities holding the corresponding license for the frequencies can get to make devices that use these frequencies.

Thus, in practice, only license holders (chip manufacturers, and telco) get to decide what code runs on the baseband chip.

So in the end :
- you could make a deblob-ed Wifi chips
- there is no legal way to make a deblob-ed baseband chip, unless you acquire your very own license.

But still, that doesn't prevent the solution mentionned by ZeroPointEnergy

To make a completely blob-free handset they'd have to design both their own wireless chips (WiFi and cellular) and GPUs (I think) so I'm pretty sure you didn't know how tall of an order that was...

Not necessarily.
- Another solution is to consider the wireless chips (Wifi and cellular) as separated self-contained boxes.
That's partly how it was done in the original OpenMoko NeoFreeRunner, how it was partially done in Golden Delicious's GTA04 board powering subsequent OpenMoko upgrade and the Pyra handheld console, and how Purism plans to do it with this phone.

Don't use chips where the baseband core is used as the whole SoC's northbridge (that's the case with tons of SoC by Qualcomm).
Instead use plain simple SoC and have the problematic standard confined in completely separated chip that only talk to the main system over a completely standard protocol.
(e.g.: Cell modem could show up as a UART serial device speaking standard "+++AT" commands, or as a USB Network device)
(e.g.: Wifi usually shows as a USB Network device in most such embed systems)
And control their power either with a software relay (Pyra ; together with a power monitor) or hardware switch (planned solution for the phone).
(e.g.: GPS could show up as a serial device speaking standard protocole)

It ends up costing a bit more (because of less integration in the SoC, and because now these chips need to be autonomous for lots of function which would otherwise have been software-defined in closed source drivers).
But this allows your phone to run 100% opensource software that you can trust, and not need to trust anything happening in those isolated chips, they can't snoop your device and violate your privacy (even less so when their power is shut down).

Have they managed to get a blob-free handset?

That where they obession with FreeScale chips comes from.
- Current planned FreeScale has a GPU that is supported by Etnaviv driver.
- They hope that the next FreeScale that they could plan to use might be supported by the time of the project completion.

For the rest (Wifi, Cell, etc.) they would plan to isolate it in self contained bloack boxes that only speak a standard protocole with the rest of the system and doesn't require anything but standard drivers in the main system (like USB-Network, or serial port, etc.).

So even in the case of an over-the-air upgrade send by a cell tower to the smartphone's cell modem, there's nothing that the NSA could do to snoop your phone activity and violate the privacy, the baseband chip would be limited to talk over a network or serial link to the main system.

[L_A_G]

Not necessarily.
- Another solution is to consider the wireless chips (Wifi and cellular) as separated self-contained boxes.

Even if you do that, the wireless chip is still performing it's job running proprietary and (most probably) completely un-audited code... The point is that you're still communicating with the outside world trough something that you can't audit and which can be exploited without you being able to tell that it's happened. Even the problem of first exploiting the wireless chip and using that to exploit what's running on the main CPU is still an issue as they need to communicate and there's always room for exploits when two systems communicate with each other.

But this allows your phone to run 100% opensource software that you can trust, and not need to trust anything happening in those isolated chips, they can't snoop your device and violate your privacy (even less so when their power is shut down).

It may be 100% open source on the host CPU, but you haven't gotten rid of ANY of the proprietary code. All you've done is wall it off a bit from the main CPU making exploitation of it trough the wireless chip a bit harder, but you haven't actually removed the problem, just mitigated it slightly.

[DrYak]

Even if you do that, the wireless chip is still performing it's job running proprietary and (most probably) completely un-audited code... The point is that you're still communicating with the outside world trough something that you can't audit and which can be exploited without you being able to tell that it's happened.

it might come as a surprise, but the whole point of networking *is* to communicate with the outside world, and you can't control the rest of the world.
the various router, access points, load balancers, and servers will all run some unauditable code.

on the other hand, using proper encryption (end-to-end and/or client-to-server) puts you in a position where you do not need to trust whatever is in between. after all, they are all just talk to over a standard network link. not something that could by standard intentionally access your memory (unlike, e.g., a bus with RDMA).

by treating problematic chips as separated box, and by forcing them to communicate exclusively over standard protocols, you simply push them away in the same "remote" category as the rest of the network.



you suddenly don't need to trust them any more than the content distribution network from which you download your upgrade RPMs - as long ad the RPM are cryptographically signed, it doesn't matter if the CDN is rogue, nor your wifi chip.

if this wifi chips "talks" in a plain network protocol, it only matter that your linux kernel has a robust network task that can survive attempts to exploit. it doesn't matter if the firmware running on the chip isn't audited, just the same as it's not important if the access point you're connected to is open or not.

Even the problem of first exploiting the wireless chip and using that to exploit what's running on the main CPU is still an issue as they need to communicate and there's always room for exploits when two systems communicate with each other.

that depends on how the wifi chip communicates with the CPU. if this shows up as a device speaking standard networking protocol (eg a a USB network device), then the only thing that matters is if the kernel's network stack is able to defend against any adversary over the network.
the smartphone isn't any more at risk from such a "networked" wifi chip, as from any other on-line stuff accessed over the network.

[L_A_G]

it might come as a surprise, but the whole point of networking *is* to communicate with the outside world, and you can't control the rest of the world.

This doesn't change the fact that you're still running closed source and un-audited code on your supposedly "fully open source" device. Compromise the wireless chip and you can still do all manner of nasty things even if you can't escalate that exploit to a full host OS exploit due to the rather part the wireless chip plays in the network stack.

on the other hand, using proper encryption (end-to-end and/or client-to-server) puts you in a position where you do not need to trust whatever is in between. after all, they are all just talk to over a standard network link. not something that could by standard intentionally access your memory (unlike, e.g., a bus with RDMA). by treating problematic chips as separated box, and by forcing them to communicate exclusively over standard protocols, you simply push them away in the same "remote" category as the rest of the network.

you suddenly don't need to trust them any more than the content distribution network from which you download your upgrade RPMs - as long ad the RPM are cryptographically signed, it doesn't matter if the CDN is rogue, nor your wifi chip. if this wifi chips "talks" in a plain network protocol, it only matter that your linux kernel has a robust network task that can survive attempts to exploit. it doesn't matter if the firmware running on the chip isn't audited, just the same as it's not important if the access point you're connected to is open or not.

Any communication between two (or more) systems can be exploited. Even if you remove RDMA from the list of tools for an attacker has at their disposal there's still going to be a huge attack surface between a network chip and it's host device. Only way you're going to get a properly secure stack for a peripheral device bus is if you make one yourself as peripheral bus stacks aren't really written with security in mind. It's not even hard to find USB-based proof-of-concept exploits with some rather horrifying levels of severity (if I'm not mistaken the documents Snowden leaked contained a number of USB-based exploit tools).

that depends on how the wifi chip communicates with the CPU. if this shows up as a device speaking standard networking protocol (eg a a USB network device), then the only thing that matters is if the kernel's network stack is able to defend against any adversary over the network.the smartphone isn't any more at risk from such a "networked" wifi chip, as from any other on-line stuff accessed over the network.

The thing about drivers is that they are generally a rather huge attack surface and most peripheral bus stacks are not written with attacks in mind. There's a reason why a scenario where an attacker has physical access to a device is considered a "game over" type situation. You mention handling the wireless chip as a USB network device as if that's somehow going to stop attackers when PoisonTap, a USB network device exploit, was first shown off about a year ago and there still isn't any real fix for it.

In all seriousness, PoisonTap goes to show that this "let's put the blob running parts into a walled off black box" mentality is just a waste of time and resources. It doesn't make exploits using these blob-running parts significantly more difficult to exploit, it only makes it slightly more difficult to escalate the exploit from the blob running part to the OS run by the host CPU.

[Ansla]

The thing about drivers is that they are generally a rather huge attack surface and most peripheral bus stacks are not written with attacks in mind. There's a reason why a scenario where an attacker has physical access to a device is considered a "game over" type situation. You mention handling the wireless chip as a USB network device as if that's somehow going to stop attackers when PoisonTap, a USB network device exploit, was first shown off about a year ago and there still isn't any real fix for it.

In all seriousness, PoisonTap goes to show that this "let's put the blob running parts into a walled off black box" mentality is just a waste of time and resources. It doesn't make exploits using these blob-running parts significantly more difficult to exploit, it only makes it slightly more difficult to escalate the exploit from the blob running part to the OS run by the host CPU.

No it doesn't. PoisonTap is hard to prevent on a general USB port (like the one you use to charge your phone, no matter what software it runs) because you want to be able to connect any type of device to it. But when you talk over USB protocol with a device that is soldered to the mainboard it's trivial to refuse to believe that it's an ethernet device when you know that's the wireless modem.

PS: And if you worry that you will now not be able to trust the information coming from the modem, that is irrelevant. You can't trust the information comming from the modem anyway, because the modem just forwards you what it received from the base tower or some device masquarading as a base tower.

[L_A_G]

No it doesn't. PoisonTap is hard to prevent on a general USB port (like the one you use to charge your phone, no matter what software it runs) because you want to be able to connect any type of device to it. But when you talk over USB protocol with a device that is soldered to the mainboard it's trivial to refuse to believe that it's an ethernet device when you know that's the wireless modem.

Way to miss the point... The device being a network device from the get-go makes the masquerading unnecessary and if the you can exploit the drivers for one type of network device you can exploit it for another. Most of the kernel code the device is going to be talking to is going to be the same code anyway so we're probably talking 90% of the same attack surface.

PS: And if you worry that you will now not be able to trust the information coming from the modem, that is irrelevant. You can't trust the information comming from the modem anyway, because the modem just forwards you what it received from the base tower or some device masquarading as a base tower.

A wireless modem does way more than that and malicious behavior from actual hardware, let alone network devices, is something the kernel was never been built to deal with. You can talk about how you can't trust network devices until the cows come home, but it doesn't do one iota to change the fact that the kernel was never written to not trust devices. The only way you can properly guard against compromised hardware doing malicious things is by doing some major kernel level system re-writes and that's obviously outside the scope of this project.

[Ansla]

Talking about missing the point, my real point is that while you talk about hypotetical issues there are already real exploits via masquarading network towers. How do you hope your open firmware to prevent this https://www.eff.org/deeplinks/2017/0...ants-stingrays?
The moment your modem is connected to such a device it will give you whatever fake data its owner wants. Just like a modem with compromised firmware would.

[ZeroPointEnergy]

A wireless modem does way more than that and malicious behavior from actual hardware, let alone network devices, is something the kernel was never been built to deal with.

You have some really good points I admit. But let's compare this to the available handsets on the market. There the baseband and wifi chipset, which is a separate processor with direct memory access can not be detected by the main operating system. While the security may not be perfect with a separated baseband, as you pointed out, at least there is the possibility that this may be detected by the OS or that improvements to the drivers could be made to detect and prevent such attacks. Without the separation the situation is basically hopeless.

Don't let perfection be the enemy of progress. Otherwise we will never improve the situation.

[L_A_G]

While the security may not be perfect with a separated baseband, as you pointed out, at least there is the possibility that this may be detected by the OS or that improvements to the drivers could be made to detect and prevent such attacks. Without the separation the situation is basically hopeless.

My point was that while this decreases the attack surface, there's still going to be an absolutely massive attack surface for anyone wanting to exploit these devices.

Don't let perfection be the enemy of progress. Otherwise we will never improve the situation.

Never said that they shouldn't do it, just that even this solution is FAR from perfect or as good as they try to make it out to be. My gripe with this thing is pretty similar to the one I have with Tesla's "Autopilot" feature. They're selling that as a full self-driving feature when it's still far from that and still has some glaring problems like not working properly in the dark and not being able to see objects properly when they're against a background of a similar color (which has caused at least one lethal accident when "Autopilot" couldn't tell a steel tractor trailer from the sky and crashed right into it without even breaking).

What I'm trying to get at here is that users should know the limits of what they're using so they don't start behaving like those limits don't exist. In the case of the Librem this could cause the next Mark Felt (a.k.a Deep Throat) to get busted because of a journalist thinking their phone can't be exploited by whatever 3 letter government agency goes after them.