Author: Todd Weaver

Founder and CEO
PGP Fingerprint: B8CA ACEA D949 30F1 23C4 642C 23CF 2E3D 2545 14F7

The Librem 5 Development Roadmap and Progress Towards i.MX 8

The Librem 5 crowdfunding campaign is still cranking along nicely, while it is going on we wanted to provide a progress report on the hardware selection as well as the advancements with our existing development boards.

TL;DR:

  • The base hardware with i.MX 6 is demonstrably working.
  • i.MX 8M, Etnaviv, full HD, are the likely hardware combination candidates for the Librem 5 phone.

Development Hardware Proving Positive

Showing photos of low-level progress is always a challenge, however showing Wayland and applications running on development hardware by definition means that the lower level parts are working! Booting from microSD into a Debian GNU/Linux unstable with most of the UI installed…

Purism Librem 5 phone (early development boards) for testing CPU/GPU and GNU/Linux
Purism Librem 5 (early development boards) booting the Linux kernel, Wayland, and a terminal in early August 2017.
Purism Librem 5 (early development boards) booting Debian GNU/Linux unstable, Wayland, and GNOME Settings in September 2017
Purism Librem 5 (early development boards) screenshot of a photo rendered

What led us to choose i.MX 6/i.MX 8

We have tested nearly every combination of CPU (and GPU, see further below), Purism’s goals of creating hardware that is ethical, runs free software, can separate baseband from main CPU, and the ability to run GNU/Linux (not Android), quickly narrowed our scope to i.MX 6 as one of the only viable options.

We have been testing and working with i.MX 6 and are pleased to report healthy progress with that hardware, as you can see from the photos, we have the Linux kernel booting, Wayland running, and in these photos GNOME/GTK and even Gnome Settings showing.

Purism Librem 5 (early development boards) running Debian GNU/Linux unstable, wayland, and GNOME Settings screenshot

Heading towards i.MX 8

We have been making some progress that makes us confident to say we will likely be able to use i.MX 8 for the Librem 5 phone hardware, primarily because:

  1. We will be able to evaluate a i.MX 8M pre-production board November 2017
  2. Our extended community can evaluate a handful of i.MX 8M sample chips in November 2017
  3. More evaluation boards should be available before year-end 2017
  4. In Q1 of 2018 we can get i.MX 8M into production. This is well ahead of our required hardware selection date of April 2018, so we will very likely be using the i.MX 8M in the Librem 5.
i.MX 8M (early evaluation boards)

State of the GPUs… or “Why we chose i.MX 6/8 + Vivante”

GPU drivers have been a big issue for a long time in the free software world. Manufacturers would typically not release any specification or documentation but only binary-only drivers. For PC hardware this problem has somewhat been resolved, which is why Purism uses Intel GPUs on our Librem products, since Intel has free drivers merged in mainline Linux kernel. But for ARM SOCs, the situation is not ideal.

  • MALI: One of the biggest players in the ARM field is MALI. The MALI core was originally developed by Falanx Microsystems until ARM bought their patents and copyrights and is now licensing the MALI core for ARM designs. ARM is not releasing any specs about the MALI GPU cores and does not provide any free software drivers for them. (The MALI400 is e.g. also used in the Allwinner A64 chip which again is used on Pine64 and in the Pinebook). There is an effort to develop a free driver by reverse engineering existing code, which is called LIMA, but its functionality and support is still limited.
  • Adreno: another big one is the Adreno GPU core, found in many Qualcomm Snapdragon SOCs. For this one also, no documentation exists although a reverse engineering project produced a pretty well working driver, called freedreno, which is also supported by current Mesa versions.
  • PowerVR: the PowerVR GPU cores are found mostly in embedded PowerPCs and Texas Instruments “OMAP” CPUs. As of today, we are not aware of any free development for these, only some binary-only drivers are available. There is an effort started by the Free Software Foundation but it seems that the project has stalled for some time now.
  • Tegra: the first generation nVIDIA “Tegra” SOCs has Linux kernel mainline support since 2012. The latest Tegra SOCs use the same GPU building blocks as the desktop PC graphics cards and can be used with the Nouveau GPU driver.
  • i.MX 6 Vivante: since Linux kernel 4.8, a new set of DRM/GPU drivers has been incorporated into the mainline Linux kernel, the so-called Etnaviv. Etnaviv support is also included in Mesa, starting with Mesa 17. We have successfully been operating a prototype for our phone using a mainline Linux kernel 4.12.4 with Etnaviv support. From microSD we booted into a Debian GNU/Linux unstable with most of the UI stuff installed. It works! We can safely say that upstream OpenGL hardware GPU support for i.MX 6 has landed in major Linux distributions, which is great news since hardware GUI acceleration is badly needed for any type of modern mobile GUI.

With the Librem 5, we are very excited to be advancing the mobile phone space to be ethical, respect digital rights, run GNU/Linux, be secure, and create a future that we are proud to be part of. We will be posting regular development updates as we progress with the hardware, software, and partners.

Purism Warrant Canary Updated July 1st 2017

Before (or on) the first day of each quarter, Purism, following the general rules of warrant canaries, will update its own Warrant Canary page if none of the listed items occurs.

warrant-canary-64x70px

Warrant Canary, July 1st 2017

  1. We have not placed any backdoors into our software or hardware, and we have not complied with any requests to do so.
  2. We have not received, nor complied with any National Security Letters or FISA court orders.
  3. We have not been subject to any gag order by a FISA court.

The next statement will be published on the first day of each quarter (January 1st, April 1st, July 1st, October 1st). Please refer to the Warrant Canary page for details and digital signatures.

How Purism Avoids Critical Intel Security Exploit

Intel dropped a fairly large bombshell on the world May 1st, 2017, when they published a security advisory that explains how nearly every single Intel chip since 2008 is now vulnerable to a remote exploit through AMT, even when powered off.

Purism, which uses Intel chips, happens to be immune to this very nasty threat. Purism happens to also be the only manufacturer where all products are designed specifically to be immune to this very substantial threat. Purism is able to accomplish this thanks to its strict belief in digital rights for users and adherence to its social purpose; it is this philosophy that brings Purism to systematically remove exploitable firmware from the computers it makes, and users are all the better for it.

We already published a lengthy article on the potential of this type of threat, which you can find at How Purism Avoids Intel AMT, but in case you wanted the shorter version:

  1. We choose Intel CPUs that do not have the hardware enabled to be exploitable (no vPro/AMT)
  2. We avoid Intel networking, to remove this exact threat (no Intel networking, no remote exploit from exploitable firmware)
  3. We neutralize the exploitable firmware

The larger message rings true; if you can’t control the computer, the computer controls you. This turn of events highlights that fact clearly; this exploitable Intel firmware is a binary at the lowest level of the CPU, outside the view of the user, allowing for anybody to use it to gain full control of the computer, even when the device is powered off. This represents the worst of all possible security vulnerabilities, and we are very proud to have a philosophy that makes our products the only high-end current hardware offering that can safely avoid this Intel security exploit.

How Purism avoids Vault 7 leaked threats “Dark Matter”

Recently, WikiLeaks unloaded another lot of Vault 7 documents, under the “Dark Matter” codename. In there, other tools and techniques used by the CIA to gain persistent remote exploits on Apple devices (including Macs and iPhones) are revealed.

Most of these attacks target Apple’s EFI/UEFI firmware, therefore such infections persist even if the operating system is re-installed. This collection of threats, including Sonic Screwdriver, Triton, Der Starke, and Dark Sea Skies, all utilize the same general principle: to attack a device at the BIOS level depth, in order to seize control of all shallower levels including the operating system, applications, networking, and web access.

In addition to the EFI/UEFI exploits mentioned, there are targeted exploits such as Night Skies focusing on iPhones, or the Sea Pea rootkit focusing on Apple’s Mac OS X kernel specifically.

Night Skies is a tool that operates in the background and does not exhibit user-alerting behavior, providing upload, download and execution capability on the device. NightSkies will attempt to use any available Internet connection to beacon. Once user activity is detected, it will monitor specific directories on the phone such as the browser history file, YouTube video cache, map files cache, or mail files metadata. Night Skies can then:

  • retrieve files from the iPhone including the address book, SMSes, call logs, etc.;
  • send files and binaries to the iPhone (such as additional hacking tools);
  • execute arbitrary commands on the iPhone;
  • grant full remote command and control;
  • masquerade as the standard HTTP protocol for communications;
  • use XXTEA block encryption to provide secure communications;
  • provide self-upgrade capability.

Sea Pea, on the other hand, is a rootkit designed for Mac OS X’s kernel, that will remain on the system unless one of the following conditions are met: the hard drive is reformatted, an upgrade is made to the next major version of OS X (i.e. 10.6), or an error is encountered (at which point SeaPea may remove itself).

What these threats continue to showcase is that EFI/UEFI is an ideal low-level backdoor to control a user’s device without their knowledge, and the leaked documents shows how widespread these threats are against any user running a EFI/UEFI BIOS.

Purism is working hard to make its products immune against these threats by designing its devices to be able to run coreboot instead EFI/UEFI. Purism also utilizes PureOS (a GNU/Linux based distribution that does not contain any mystery binaries), so the entire source code stack can be audited.

These documents continue to reinforce the fact that security is a game of depth, and the deeper you go with releasing free software where the source code can be audited, the better.

Purism has future plans of including hardware encryption tools to verify the entire boot chain, putting the entire system under a user’s control, rather than that of a bad corporation, government, spying agency, criminals, or ISPs.

Yet Another EFI/UEFI Exploit, this one Utilizing NVRAM and Persistent Storage

Continuing on our previous post on this topic, another EFI/UEFI BIOS exploit theoretically known–and even proven to work by Trammel hudson some years ago–that resurfaced through the Vault 7 documents, is the EFI/UEFI exploit that can write to NVRAM or persistent storage. This means that this exploit cannot be detected from hard drive inspection, and can survive through a complete OS reinstall if you’re using EFI/UEFI (which is not a problem for Purism users running coreboot).

The CIA documents describe it best:

“These variables present interesting opportunities for our tools since they will survive a OS reinstall and are invisible to a forensic image of the hard drive. What’s also interesting is that there is no way to enumerate NVRAM variables from the OS… you have to know the exact GUID and name of the variable to even determine that it exists.” — the CIA, as leaked through the Vault 7 Persistent Storage Document

This line also summarizes intent for the exploit:

“This might be a good place to put either implants or encryption keys. If every implant deployment used a different GUID/name pair, it would make the variables a bit more difficult to discover.” — the CIA, from the Vault 7 Persistent Storage Document

This continues to reinforce that our philosophy and beliefs are the only way to have long-term products that respects users’ digital rights.

Proving the Known, EFI/UEFI Exploited for BIOS Level Attacks

We’re continuing with a second report (many more coming!) on the “Vault 7” Documents we started digesting recently. There is an extensive section dedicated to EFI/UEFI exploitations. While this threat has been known from a theoretical standpoint from the moment the non-free BIOS replacement–EFI/UEFI–came into existence, the Vault 7 documents published recently now confirm that these threats are real and these weaknesses are actively being exploited.

One interesting read we’re focusing on today is the EFI/UEFI “ExitBootServices Hooking” exploit and sample copy-and-paste code to inject a hook into the last execute state of the EFI/UEFI process (the “ExitBootServices”).

Copy-and-paste code was included in the leaks which allow for the exploitation of UEFI-based boot systems by altering the operating system’s kernel which is loaded into memory before exiting the UEFI boot sequence. The copy-and-paste code allows for an attacker to insert a custom hook which can be used to arbitrarily alter the operating system’s kernel in memory immediately before execution control is handed to the kernel. — Wikipedia’s summary.

It is trivial to utilize this exploit:

Because the ExitBootServices service can be found by getting its pointer from the global EFI_BOOT_SERVICES table, hooking the ExitBootServices call is trivial. […] When you’re running in UEFI, that EFI_BOOT_SERVICES table isn’t protected by anything, so you can just write directly to it. — Vault 7 ExitBootServices Hooking

The result is that the entire system is compromised. As the page highlights, “At this point, you can do whatever you want.”

This type of exploit once-again highlights that security is a game of depth. This exploit is one level below the kernel, which means it has complete control of every level above it, such as the kernel, the entire operating system, any and all applications, network traffic, web application usage, and all user interaction.

The good news is, Purism recently completed the port of coreboot to the Librem 13 v1 (with more ports to come for the rest of our devices), providing a free/libre and open source replacement for EFI/UEFI which avoids all of the exploits mentioned within the documents.

The only long-term approach to protect oneself is to have complete control of the device. Control is the key word, and there is no other way to have complete control than to have as much of the software released under free software licenses where the source code is available to confirm it operates in your best interest and not that of criminals, spies, bad hackers, nations, or thieves.

Confirming that EFI/UEFI has a known and trivial exploit that is built into the standard also confirms that there is no depth too deep to exploit, and the only defense against unwanted stripping of a users’ digital rights is to use hardware and software that you control. Purism does just that by releasing all software under a free software license where the source code is available to be audited, reviewed, and scrutinized making a user control their device not the device controlling the user.

What the US Senate Vote Barring the FCC from Protecting the Privacy of Customers Means

On March 23rd, 2017 the US Congress disapproved the rule submitted by the Federal Communications Commission relating to “Protecting the Privacy of Customers of Broadband and Other Telecommunications Services”, and so that rule shall have no force or effect.

This means the FCC does not have the legal authority to protect the privacy of customers from ISPs gobbling up all the data they want to. The ISPs own the connection from your router to the Internet at large. ISPs have access to everything that passes over the connection including any non-encrypted content such as, every webpage you visit, every email you send, every photo you share, every document you deliver, and any social media post you make. Utilizing SSL helps guard against this threat of ISPs selling your head-end usage data, which is why Purism integrates EFF‘s HTTPS Everywhere in PureOS by default. In the future Purism will also be including SSL tunneling by default to help users stop ISPs from the privacy invading fire-hose of everything you do online.

What the CIA Vault 7 Documents Mean

WikiLeaks has recently released a treasure trove of documents, codenamed Vault 7, that will take weeks to digest. And we will digest it all. But before we go document by document, we wanted to address top-level concerns users have, and how our philosophy and business model are the only ones that can withstand the test of time against this type of user device control. Read more

Todd’s Purism Librem 13 experience with coreboot and a neutralized ME

A few days ago, I got to experience the efforts of a culmination of free software supporters; from Purism team members, ME hackers, coreboot developers, and a lot of other individuals. I am very pleased to run a Librem 13 with coreboot, running a neutralized Intel Management Engine, and no microcode update. I used that setup to type this blog post! Read more

Growing to Ship from Inventory in 2017

Thank you all for supporting Purism, with ordering hardware, donations, volunteering, downloading PureOS, using our products, and of course the kind words. We are excited to finally approach the transition from “build-to-order” (where users have tended to wait months for Librem products) to shipping from inventory, where new users will be waiting merely days for Librem products. This is the most important step we’re taking yet.

To do this, we are leveraging past sales revenue to get investment and a larger line-of-credit, so we can place an even larger order for all the supplies, hardware, and component parts needed to build and house inventory.

The Librem 13 v2 prototype
The Librem 13 v2 prototype

This larger order is expected to be placed in January, and we intend it to include: the Librem 13 v2, the Librem 15 v2, and the Librem 11 v1. There is typically an 8 week lead time for fabrication, which means placing our bulk inventory orders in January will allow us to fulfill the remaining preorders and backorders in March, and ship-from-inventory beginning in April of 2017.

This is a very exciting transition for Purism to grow to meet the demand of users worldwide, and we could not have done this without your support, so thank you again.