Pinephone proprietary bs


#1

Heard pinephone wasn’t completely open source. Did they do anything to segregate proprietary code, how bad could it be and how much of it is and for what functuons is it for?


#2

They have a nice forum for all of their devices: https://forum.pine64.org/index.php


#3

They have this article setting the record straight pinephone misconceptions

I think the OS would load the binary drivers to the devices on startup and then they are separated. This is why a lot of Linux distros cannot get FSF approval (?). Purism keeps the binary drivers (less than what pinephone requires?) on separate memory from the OS to keep total separation and Purim’s goal is to help vendors to use open-source code (?). It’s up to the OSs on the pinephone to not contain any other proprietary software then the drivers to initialise the device.

@user1 are you referring to anything else or have more questions?


#4

The only proprietary bits in the PinePhone is the firmware for the Realtek WiFi/Bluetooth, which is stored in /lib/firmware/, plus there is optional proprietary firmware for the camera to provide auto-focus. I don’t think the RealTek and camera firmware in the PinePhone is a security problem.

More important to me is that Purism is working to add support for new hardware in the Linux kernel and Purism selects companies like NXP and Redpine Signals that have a history of working with the community. In contrast, PinePhone is using older hardware that is already supported by the Linux kernel and it uses chips from Allwinner and Realtek, which are two companies that have violated the GPL.

Purism’s collaboration with Redpine Signals is important because it gives us 802.11n that has decent reception with energy efficiency and doesn’t need proprietary drivers/firmware in the Linux file system. Before the RS9116, the only option for 802.11n without proprietary files in the Linux file system was an outdated Atheros chip that is crappy, which is why there are so many complaints about the WiFi in the Librem 13/15. For more, see the “Runs on 100% Free Software” section in my article.


#5

But price difference is significant Two comments on this post mentioned the L5 but my question wasn’t about comparing the two devices but just talking about one. People don’t make the comparison an add on to a statement but rather the main arguement which annoys me.


#6

The drivers in both the PinePhone and Librem 5 are all free/open source, but the PinePhone has proprietary firmware for the Realtek WiFi/BT and the optional camera auto-focus. The difference is that drivers are executed by the kernel, whereas the Linux kernel copies firmware (from a directory like /lib/firmware/) and passes it to a component when that component starts up. Because firmware doesn’t execute like drivers, there is less danger of it being a security risk inside the Linux kernel (although it could have security holes when it is executing inside the component).

On the Librem 5, the only proprietary software (aside from the firmware which is stored inside components), is a bit of code to train the DDR RAM timing which is executed by uboot when the Librem 5 boots. That code is stored in a separate SPI Flash memory chip and it is executed by the separate Cortex-M4F core. If proprietary code does not require updating, if is not stored in the Linux file system, and if is executed by a separate processor or processing core from the cores where the operating system is executing, then the FSF regards it as part of the hardware, so it doesn’t violate the Respects Your Freedom certification.


#7

In particular, if the hardware interface is one where the component has direct access to main memory then it is even more of a concern that a component is running blackbox firmware.

I don’t know whether that (access to main memory) applies in the PinePhone.

I am fairly sure that it does not apply in the Librem 5 because that would be one of the design goals (even though theoretically it reduces potential peak performance).

Once that issue has been dealt with, one has to face the issue of the closed, untrusted component in its own right. At the end of the day if the component is completely compromised, it doesn’t make much difference whether it is

  • hardware
  • embedded firmware (not loaded by the OS)
  • blackbox firmware loaded by the OS

and you have to look at mitigation e.g. a dodgy (closed, blackbox) WiFi card (which applies almost universally) can be mitigated by only running secure protocols above the link layer e.g. IPSec, TLS, SSH, … - which is no different from the internet as a whole, which should be assumed to be dodgy.


#8

The Realtek WiFi/BT on the PinePhone is connected via USB 2.0, so there is no risk of its firmware getting direct memory access (DMA). The risk is when components are connected via a PCI bus, because that allows DMA, but the Librem 5 and PinePhone don’t use PCI to connect their components. (I wish that we had the option of using PCI through the M.2 slot on the Librem 5, but I assume that will be disabled for security reasons.)

From a security perspective, the PinePhone’s design is pretty good, but the Librem 5 is even better, because it has accessible hardware kill switches, a OpenPGP card slot, the GNSS is separated from the cellular modem, PureOS and the web browser are preconfigured for security/privacy, eventual support of the Librem Key to detect tampering, published x-rays of PCB to detect spy chips, and optional anti-interdiction service.