As you might have noted when we announced closing the development kit “last call” sale, new specifications have been made public. I want to explain what led to these specifications and why we made the choices we made and what the current timeline is for the devkits and Librem 5 phones. Read more
This post is based off of “Freedom, Security and Privacy” a keynote I gave at OpenWest 2018. You can see the full video of the talk here.
Freedom, security and privacy are interrelated. The relationship between these three concepts is more obvious in some cases than others, though. For instance, most people would recognize that privacy is an important part of freedom. In fact, studies have shown that being under surveillance changes your behavior such as one study that demonstrates that knowing you are under surveillance silences dissenting views. The link between privacy and security is also pretty strong, since often you rely on security (encryption, locked doors) to protect your privacy.
The link between freedom and security may be less obvious than the others. This is because security often relies on secrecy. You wouldn’t publish your password, safe combination or debit card PIN for the world to see, after all. Some people take the idea that security sometimes relies on secrecy to mean that secrecy automatically makes things more secure. They then extend that logic to hardware and software: if secret things are more secure, and proprietary hardware and software are secret, therefore proprietary hardware and software must be more secure than a free alternative.
The reality is that freedom, security and privacy are not just interrelated, they are interdependent. In this post I will analyze the link between these three concepts and in particular how freedom strengthens security and privacy with real world examples.
Do Many Eyes Make Security Bugs Shallow?
A core tenet of the Free Software movement is “many eyes make bugs shallow.” This statement refers to the fact that with proprietary software you have a limited amount of developers who are able to inspect the code. With Free Software, everyone is free to inspect the code and as a result you end up with more people (and more diverse people) looking at the code. These diverse eyes are more likely to find bugs than if the code were proprietary.
Some people extend this idea to say that many eyes also make security bugs shallow. To that I offer the following counterpoint: OpenSSL, Bash and Imagemagick. All three of these projects are examples where the code was available for everyone to inspect, but each project had critical security bugs hiding inside of the code for years before it was found. In particular in the case of Imagemagick, I’m all but certain that security researchers were motivated by the recent bugs in OpenSSL and Bash to look for bugs in other Free Software projects that were included in many embedded devices. Now before anyone in the proprietary software world gets too smug, I’d also like to offer a counter-counterpoint: Flash, Acrobat Reader and Internet Explorer. All three of these are from a similar vintage as the Free Software examples and all three are great examples of proprietary software projects that have a horrible security track record.
So what does this mean? For security bugs, it’s not sufficient for many eyes to look at code–security bugs need the right eyes looking at the code. Whether the researcher is fuzzing a black box, reverse engineering a binary, or looking directly at the source code, security researchers will find bugs if they look.
When Security Reduces Freedom
At Purism we not only develop hardware, we also develop the PureOS operating system that runs on our hardware. PureOS doesn’t have to run on Purism hardware, however, and we’ve heard from customers who use PureOS on other laptops and desktops. Because of this, we sometimes will test out PureOS on other hardware to see how it performs. One day, we decided to test out PureOS on a low-end lightweight notebook, yet when we went to launch the installer, we discovered that the notebook refused to boot it! It turns out that Secure Boot was preventing the PureOS installer from running.
What is Secure Boot and why is it problematic?
Secure Boot is a security feature added to UEFI systems that aims to protect systems from malware that might attack the boot loader and attempt to hide from the operating system (by infecting it while it boots). Secure Boot works by requiring that any code it runs at boot time be signed by a certificate from Microsoft or from vendors that Microsoft has certified. The assumption here is that an attacker would not be able to access the private keys from Microsoft or one of its approved vendors to be able to sign its own malicious code. Because of that, Secure Boot can prevent the attacker from running code at boot.
When Secure Boot was first announced, the Linux community got in quite an uproar over the idea that Microsoft would be able to block Linux distributions from booting on hardware. The counter-argument was that a user could also opt to disable Secure Boot in the UEFI settings at boot time and boot whatever they want. Some distributions like Red Hat and Ubuntu have taken the additional step of getting their boot code signed so you can install either of those distributions even with Secure Boot enabled.
Debian has not yet gotten their boot code signed for Secure Boot and since PureOS is based off of Debian, this also means it cannot boot when UEFI’s Secure Boot is enabled. You might ask what the big deal was since all we had to do is disable Secure Boot and install PureOS. Unfortunately, some low-cost hardware saves costs by loading a very limited UEFI configuration that doesn’t give you the full range of UEFI options such as changing Secure Boot. That particular laptop fell into this category so we couldn’t disable Secure Boot and as a result we couldn’t install our OS–we were limited to operating systems that partnered with Microsoft and its approved vendors.
Secure Booting: Now with Extra Freedom
It’s clear that protecting your boot code from tampering is a nice security feature, but is that possible without restricting your freedom to install any OS you want? Isn’t the only viable solution having a centralized vendor sign approved programs? It turns out that Free Software has provided a solution in the form of Heads, a program that runs within a Free Software BIOS to detect the same kind of tampering Secure Boot protects you from, only with keys that are fully under your control!
The way that Heads works is that it uses a special independent chip on your motherboard called the TPM to store measurements from the BIOS. When the system boots up, the BIOS sends measurements of itself to the TPM. If those measurements match the valid measurements you set up previously, it unlocks a secret that Heads uses to prove to you it hasn’t been tampered with. Once you feel confident that Heads is safe, you can tell it to boot your OS and Heads will then check all of the files in the /boot directory (the OS kernel and supporting boot files) to make sure they haven’t been tampered with. Heads uses your own GPG key signatures to validate these files and if it detects anything has been tampered with, it sends you a warning so you know not to trust the machine and not to type in any disk decryption keys or other secrets.
With Heads, you get the same kind of protection from tampering as Secure Boot, but you can choose to change both the TPM secrets and the GPG keys Heads uses at any time–everything is under your control. Plus since Heads is Free Software, you can customize and extend it to behave exactly as you want, which means an IT department could customize it to tell the user to turn the computer over to IT if Heads detects tampering.
When Security without Freedom Reduces Privacy
Security is often used to protect privacy, but without freedom, an attacker can more easily subvert security to exploit privacy. Since the end-user can’t easily inspect proprietary firmware, an attacker who can exploit that firmware can implant a backdoor that can go unseen for years. Here are two specific examples where the NSA took advantage of this so they could snoop on targets without their knowing.
- NSA Backdoors in Cisco Products: Glenn Greenwald was one of the reporters who initially broke the Edward Snowden NSA story. In his memoir of those events, No Place to Hide, Greenwald describes a new NSA program where the NSA would intercept Cisco products that were shipping overseas, plant back doors in them, then repackage them with the factory seals. The goal was to use those back doors to snoop on otherwise protected network traffic going over that hardware. Update: Five new backdoors have been discovered in Cisco routers during the beginning of 2018, although whether they were intentional or accidental has not been determined.
- NSA Backdoors in Juniper Products: Just in case you are on Team Juniper instead of Team Cisco, it turns out you weren’t excluded. The NSA is suspected in a back door found in Juniper firewall products within its ScreenOS that had been there since mid-2012. The backdoor allowed admin access to Juniper firewalls over SSH and also enabled the decryption of VPN sessions within the firewall–both very handy if you want to defeat the privacy of people using those products.
While I picked on network hardware in my examples, there are plenty of other examples outside of Cisco, Juniper, and the NSA where because of a disgruntled admin, a developer bug, or paid spyware, a backdoor or default credentials showed up inside proprietary firmware in a security product. The fact is, this is a difficult if not impossible problem to solve with proprietary software because there’s no way for an end user to verify that the software they get from their vendor matches the source code that was used to build it, much less actually audit that source code for back doors.
When Freedom Protects Security and Privacy
The Free Software movement is blazing the trail for secure and trustworthy software via the reproducible builds initiative. For the most part, people don’t install software directly from the source code but instead a vendor takes code from an upstream project, compiles it, and creates a binary file for you to use. In addition to a number of other benefits, using pre-compiled software saves the end user both the time and the space it would take to build software themselves. The problem is, an attacker could inject their own malicious code at the software vendor and even though the source code itself is Free Software, their malicious code could still hide inside the binary.
Reproducible builds attempt to answer the question: “does the binary I get from my vendor match the upstream source code that was used to build it?” This process uses the freely-available source code from a project to test for any tampering that could have happened between the source code repository, the vendor, and you making sure that a particular version of source code will generate the same exact output each time it is built, regardless of the system that builds it. That way, if you want to verify that a particular piece of software is safe, you can download the source code directly from the upstream developer, build it yourself, and once you have the binary you can compare your binary with the binary you got from your vendor. If both binaries match, the code is safe, if not, it could have been tampered with.
Debian is working to make all of its packages reproducible and software projects such as Arch, Fedora, Qubes, Heads, Tails, coreboot and many others are also working on their own implementations. This gives the end user an ability to detect tampering that would be impossible to detect with proprietary software since by definition there’s no way for you to download the source code and validate it yourself.
Freedom, Security and Privacy in Your Pocket
Another great example of the interplay between freedom, security and privacy can be found by comparing the two operating systems just about everyone carries around with them in their pockets: iOS and Android. Let’s rate the freedom, security and privacy of both of these products on a scale of 1 to 10.
In the case of iOS, it’s pretty safe to say that the general consensus puts iOS security near the top of the scale as it often stands up to government-level attacks. When it comes to privacy, we only really have Apple’s marketing and other public statements to go by, however because they don’t seem to directly profit off of user data (although apps still could), we can cut them a bit of a break. When it comes to freedom, however, clearly their walled garden approach to app development and their tight secrecy around their own code gives them a low rating so the end result is:
- Security: 9
- Privacy: 6
- Freedom: 1
Now let’s look at Android. While I’m sure some Android fans might disagree, the general consensus among the security community seems to be that Android is not as secure as iOS so let’s put their security a bit lower. When it comes to freedom, if you dig far enough into Android you will find a gooey Linux center along with a number of other base components that Google is using from the Free Software community such that outside parties have been able to build their own stripped-down versions of Android from the source code. While you have the option to load applications outside of Google’s Play Store, most of the apps you will find there along with almost all of Google’s own apps are proprietary, so their freedom rating is a mixed-bag. When it comes to privacy though, I think it’s pretty safe to rate it very low, given the fundamental business model behind Android is to collect and sell user data.
- Security: 7
- Freedom: 5
- Privacy: 1
Over the long run, the Librem line of products aims to address these concerns.
Why Not All Three?
To protect your own security and privacy, you need freedom and control. Without freedom, security and privacy require the full trust of vendors. However, vendors don’t always have your best interests at heart; in fact, in many cases vendors have a financial incentive to violate your interests, especially when it comes to privacy. The problem is, with proprietary software it can be difficult to prove a vendor is untrustworthy and if you do prove it, it’s even harder to revoke that trust.
With Free Software products, you have control of your trust. You also have the ability to verify that your Free Software vendors are trustworthy. With reproducible builds, you can download the source code and verify it all yourself.
In the end, freedom results in stronger security and privacy. These three concepts aren’t just interrelated, but they are interdependent. As you increase freedom, you increase security and privacy and when you decrease freedom, you put security and privacy at risk. This is why we design all of our products with freedom, security and privacy as strict requirements and continue to work toward increasing all three in everything we do.
While investigating using the i.MX 8 for the Librem 5 phone we found an issue that would have been problematic for us to obtain the Free Software Foundation’s “Respects Your Freedom” (RYF) hardware endorsement:
- In U-Boot there are a number of firmware blobs that need to be loaded into the DDR PHY so that it can be trained to work with DDR4. This training is done on every boot.
- The normal boot sequence for the i.MX 8 is that the internal ROM loader loads the Secondary Program Loader (SPL) which, in this case, is a small version of U-Boot that can initialize the DDR and load the full U-Boot into DDR to finish the boot process. Very early in the SPL, the training blobs get loaded into the DDR PHY and the training sequence is run. The DDR training procedure is completely un-documented so re-writing the firmware blobs with free/libre or open source versions would be an arduous process.
- We can’t ignore the DDR PHY because it is interface between the i.MX 8 internal buses and the DDR4 chips outside of the SOC. The DDR PHY is also part of the i.MX 8 silicon so we can’t just replace the DDR PHY with a different one. It also appears that all DDR PHY’s required this training to work with DDR4, so going to a different SOC wouldn’t solve it either.
The RYF has a “secondary processor” exclusion that can be granted on a case by case basis. We will leverage this exclusion to load and train the DDR PHY on the i.MX 8. We will use a secondary processor to keep binary blobs out of u-boot and the kernel. Read more
PureOS is a general purpose operating system that is based on the Linux kernel and is focused on being an entirely Free (as in freedom) OS. It is officially endorsed by the Free Software Foundation. We adhere to the Debian Social Contract and the GNU FSDG.
PureOS aims to match and surpass mainstream operating systems (such as Windows and macOS) by striking the balance between security and usability, to provide the best possible out-of-the-box experience paired with the best privacy, security, and software freedom protections possible. The idea is to make it easy to feel safe and secure with an operating system you can trust from the ground up and with appropriate tools. Read more
At Purism, we are just as excited as you are about the the development boards that will be distributed this summer. Once a person receives their development board, their first thought will be “This is great! Now, what do I do with it?” In anticipation of the technical guidance that will be needed, the developer documentation effort has begun. You can already see the current state of the documentation at developer.shop.puri.sm
Goal of the Docs
The developer documentation is there as a guide for getting a new developer setup and ready to start having fun! This will include plenty of examples that will help you along towards whatever your goal with the development board may be.
There will be technical step-by-step instructions that are suitable for both newbies and experienced Debian developers alike. The goal of the docs is to openly welcome you and light your path along the way with examples and links to external documentation. These examples will aid you from the start of unpacking your development board to building and deploying flatpak applications to it—and eventually including your package into PureOS. Included, you can expect examples on how to use certain tools like flatpak, the IDEs used to build flatpak applications, and UI tools to help you design apps. The design of the Librem 5 phone interface will also be outlined in detail to provide insight into the human interface guidelines that will be followed by the core applications. Use the design section to learn about gestures you can expect on the phone. Apps you design or port to the board can use these gestures too!
Please note that the docs are not a complete tutorial on how to use all of the development tools required. There are existing documentations available for each specific tool so there’s no need to reinvent the wheel. Instead, you will be directed to those locations online so you can research further on a specific tool.
We welcome all test and development efforts that volunteers have to give, so there will also be information on volunteering and how to become a Purism community member in general.
Work in progress
The documentation is in a constant state of flux. Content is being added daily and reorganization still occurs from time-to-time. If you no longer see a page there, just search for it because chances are it has been moved to somewhere else within the site instead of removed. The aim is to write documentation that is helpful and intuitive so it is important that an intuitive path is laid out. This developer documentation is still pretty new but is filling out quickly so that you are ready to hit the ground running with your new development board in June!
There will be a separate announcement in the next few weeks on this same blog to call for volunteers so get ready!
Librem devices add tamper-evident features to further protect users from cybersecurity threats by offering users the full control that no mainstream computer manufacturer ever has before
SAN FRANCISCO, Calif., February 27, 2018 — Purism, maker of security-focused laptops has announced today that they have successfully tested integration of Trammel Hudson’s Heads security firmware into their Trusted Platform Module (TPM)-enabled coreboot-running Librem laptops. This integration allows Librem laptop users to freely inspect the code, build and install it (and customize it) themselves, and own control of the secure boot process as Heads uses the TPM on the system to provide tamper-evidence. Read more
Back from FOSDEM
Being at FOSDEM 2018 was a blast! We received a lot of great feedback about what we have accomplished and what we aim to achieve. These sorts of constructive critiques from our community are how we grow and thrive so thank you so much for this! It helps us to focus our development. Moreover, I was very impressed by the appreciation that we received from the free software community. I know that relationships between companies, even Social Purpose Corporations—like Purism, and the free software communities are a delicate balance. You need to find a good balance between being transparent, open, and free on one side but also having revenue to sustain the development on the other side. The positive feedback we received at FOSDEM and the appreciation that was expressed for our projects was great to hear.
We are working really hard on making ethical products, based on free/libre and open source software a reality. This is not “just a job” for anybody on the Purism staff, we all love what we do and deeply believe in the good cause we are working so hard to achieve. Your appreciation and feedback is the fuel that drives us to work on it even harder. Thank you so much!
As I mentioned before, we have the i.MX 6 QuadPlus test hardware on hand, so here are some photos of our development board actually running something:
On the right, you can see the Nitrogen board with the modem card installed. On the left is our display running a browser displaying the Purism web-page and below it a terminal window in which I started the browser. To put the resolution of the display into perspective I put a Micro SD card on the display:
The terminal window is about as big as three Micro SD cards! This makes it very clear that a lot of work has to be put into making applications usable on a high resolution screen and to make them finger friendly since the only input system we have is the touch screen. In the next picture I put an Euro coin on the screen and switched back to text console:
Concerning the software, we are working on getting the basic framework to work with the hardware we have at hand. One essential piece is the middleware that handles the mobile modem that deals with making phone calls and sending and receiving SMS text messages. For this we want to bring up oFono since it is also used by KDE Plasma mobile. We have a first success to share:
This is the first SMS sent through oFono from the iMX board and the attached modem to a regular mobile smartphone where the screenshot was taken. So we are on the right track here and have a solution that is starting to work that suits multiple possible systems, like Plasma mobile or a future GNOME/GTK+ based mobile environment.
The SMS was sent with a python script using the native oFono DBus API. First the kernel drivers for the modem had to be enabled followed by running ofonod which autodetects the modem. Next the modem must be enabled and brought online (online-modem). Once this was done sending an SMS was as simple as:
purism@pureos:~/ofono/test$ sudo ./send-sms 07XXXXXXXXX "Sent from my Librem 5 i.MX6 dev board!"
The script itself is very simple and instructive. Simulating the reception of a text message can also be done, with a command such as this one:
purism@pureos:~/ofono/test$ sudo ./receive-smsb 'Sent to my Librem 5 i.MX6 dev board!' LocalSentTime = 2018-02-07T10:26:19+0000 SentTime = 2018-02-07T10:26:19+0000 Sender = +447XXXXXXXXX
The evolution of mobile hardware manufacturing
We are building a phone, so hardware is an important part of the process. In our last blog post we talked a bit about researching hardware manufacturing partners. Since we are not building yet-another Qualcomm SOC based phone, but starting from scratch, we are working to narrow down all the design choices and fabrication partners in the coming months. This additional research phase has everything to do with how the mobile phone hardware market has evolved in the past years and I want to share how this all works with you.
In the early days of smartphones, a common case was that the main CPU was separated from the cellular baseband modem and that the cellular modem would run its own firmware when implementing all of the necessary protocols that operate the radio interface—at first it was GSM, then UMTS (3G) and finally LTE (4G). These protocols and the handling of the radio interface have become so complex that the necessary computational power for handling this as well as the firmware sizes have grown over time. Current 3G/4G modems include a firmware of 60 or more megabytes are becoming more common. It did not take long before storing this firmware became an issue as well as at run time since this requires significant increases of RAM usage.
Smartphones usually have a second CPU core for the main operating system which also runs the phone applications and interacts with the users. This means that your device must have two RAM systems as well, one for the baseband and one for the host CPU. This also means you need two storages for firmware, one for the host CPU and one for the baseband. As you may imagine, getting all of these components working together in a form factor small enough to fit into someone’s hand takes a lot of development and manufacturing resources.
The advent of cheap smartphones
There is extreme pressure about the cost of smartphones. In today’s commodity market, we see simple smartphones starting at prices less than $100 USD.
The introduction of combined chips, with radio baseband plus host CPU on one silicon die inside one chip, massively reduced costs. This allows the host CPU and baseband to share RAM and storage. Since the radio can be made in the same silicon process as the host CPU, and both can be placed in a single chip package, we see substantial cost reduction in the semiconductor manufacturing as well as the cost of manufacturing the device. This saves you from having to use a second large chip for the radio itself, an extra flash chip for its firmware, and possibly an extra RAM chip for its operation. This does not only reduce the Bill of Materials (BOM), but also PCB space, and it enables the creation of even smaller and thinner devices. Today we see many big companies offer these types of combined chipsets—such as Qualcomm, Broadcom, and Mediatek to name a few.
These chips caused a big shift in the mobile baseband modem market. Formerly it was common to find discrete baseband modems on the market that were applicable for mobile battery powered handsets like the one we are developing. But since the rise of the combined chipsets, the need for separated modems has dropped to a level that does not justify their development as much. You can still find modem modules and cards but these modules are usually targeted for M2M (machine to machine) communication with only limited data rates and most of them do not have audio/voice functions. They usually come in pretty large cards, such as the miniPCIe or M.2. For us this means that our choice of separated baseband modems suitable for a phone is narrowed.
What this means for OEM, ODM or Build it Yourself
All of this consolidation has an impact on hardware manufacturers and our choices. Pretty much all current smartphone designs by OEM/ODM manufacturers are based on the combined chipset types; this is all they know and it is where they have expertise. Almost no one is making phones with separated basebands anymore, and the ones who do are not OEMs nor ODMs. The options are further limited by our requirement not to include any proprietary firmware on our host CPU (which we wrote about before): most fabricators are unfamiliar with i.MX 6 or i.MX 8 and do not want to risk a development based on it, which narrows our hardware design and manufacturing partners to a much smaller list.
However, we have some promising partners that we will continue to evaluate, and we are confident that we are going to be able to design and manufacture the Librem 5 as we originally specified. We just wanted to share with you why making this particular hardware is so challenging and why our team is the best one to execute on this design. To continue to discuss with some of the manufacturers and providers, Purism will visit Embedded World, one of the world’s largest embedded electronics trade shows, in Nürnberg (Germany) in the beginning of March. And, as usual, we will continue to keep you updated on our progress!
Good news with our existing evaluation boards
We have been patiently waiting for the i.MX 8M to become available, all according to the forecast timeline from NXP. In the meantime, we have started developing software using the i.MX 6 QuadPlus board from Boundary Devices, specifically the NITROGEN6_MAX (Nit6Qp_MAX) since it is the closest we get to production devices before NXP releases the i.MX 8M. We have a Debian Testing based image running as a testbed on these boards while the PureOS team is preparing to build PureOS for ARM and ARM64 in special.
On these evaluation boards we have all the interfaces that we need for software development:
- Video input and output
- USB for input devices
- Serial console and a miniPCIe socket with SIM card connected for attaching a mobile modem
- At the moment, we are using a Sierra Wireless MC7455 LTE miniPCIe modem card for development, which uses a Qualcomm MDM9230 baseband modem chip. This card is basically a USB device in a mPCIe form factor, i.e. we do not actually use the PCIe interface.
- An extremely nice display to our kits using an HDMI-to-MIPI adapter board. The display is a 5.5″ AMOLED display with full-HD resolution with the native orientation as portrait mode.
This hardware setup allows us to start a lot of the software development work now to ensure our development continues in parallel until we have the i.MX 8M based hardware in hand.
Next on our to-do list: phone calls!
The Librem 5 and recent industry news
Lately, news headlines have been packed with discussions about critical CPU bugs which are not only found in Intel CPUs, but also partially in AMD CPUs and some ARM cores. At the same time, some of our backers have voiced concerns about the future of NXP in light of a potential acquisition by Qualcomm. Therefore you might be wondering, “Will the Librem 5 be affected by these bugs too?” and “will the Purism team get the i.MX 8 chips as planned?”, so let’s address those questions now.
Not affected by Spectre/Meltdown
At the moment we are pretty confident that we will be using one of NXP’s new i.MX 8 family of CPUs/SOCs for the Librem 5 phone. More specifically we are looking at the i.MX 8M which features four ARM Cortex A53 cores. According to ARM, these cores are not affected by the issues now known as Spectre or Meltdown, which ARM’s announcement summarizes in their security update bulletin.
So for the moment we are pretty sure that the Librem 5 phone will not be affected, however we will continue to keep an eye on the situation since more information about these bugs is surfacing regularly. In this respect we can also happily report that we have a new consultant assisting our team in security questions concerning hardware-aided security as well as questions like “is the phone’s CPU affected by Spectre/Meltdown or not”.
Qualcomm possibly buying NXP: not a concern
For quite some time there have been rumors that Qualcomm might have an interest in acquiring NXP. Since we will be using an NXP chip as the main CPU, specifically one of the i.MX 8 family, we are well aware of this development and are watching it closely.
Qualcomm is an industry leader for high volume consumer electronics whereas NXP targets lower volume industrial customers. This results in pretty different approaches concerning support, especially for free software. Where NXP traditionally is pretty open with specifications, Qualcomm is rather hard to get information from. This is very well reflected by the Linux kernel support for the respective chips. The question is how would it affect continued free software support and availability of information on NXP SOCs if Qualcomm acquires NXP?
First, it is unlikely that this deal will happen at all. Qualcomm had a pretty bad financial year in 2017 so they might not be in the financial position to buy another company. Second, there is a rumor that Broadcom might acquire Qualcomm first. Third, international monopoly control organizations are still investigating if they can allow such a merger at all. Just a few days ago the EU monopoly control agreed to allow the merge but with substantial constraints, for example Qualcomm would have to license several patents free of charge, etc. Finally, there are industry obligations that NXP cannot drop easily: the way NXP works with small and medium sized customers is a cornerstone of many products and customers; changing this would severely hamper all of those businesses involved, and these changes might cause bad reputation, bad marketing and loss of market share.
So all in all, this merger is not really likely to happen soon and there would probably not be changes for existing products like the i.MX 8 family. If the merger happens it might affect future/unreleased products.
In addition to working on obtaining i.MX6QuadPlus development boards to be able to work properly, the phone team is also intensively researching and evaluating software that we will base our development efforts on during the next few months. We are well aware of the huge amount of work ahead of us and the great responsibility that we have committed to. As part of this research, we reached out to the GNOME human interface design team with whom we began discussions on design as well as implementation. For example, we started to implement a proof of concept widget that would make it much easier to adapt existing desktop applications to a phone or even other style of user interface. What we would like to achieve is a convergence of devices so that a single application can adapt to the user interface it is currently being used with. This is still a long way ahead of us, but we are working on it now. We will meet up also with some GNOME team members at FOSDEM to discuss possible development and design goals as well as collaboration possibilities.
The mobile development work for KDE/Plasma will primarily be performed by their own human interface teams. Purism will be supporting their efforts through supplying hardware and documentation about our phone development progress as it is happening. This will help ensure that that KDE/Plasma will function properly on the Librem 5 right from the factory. To understand better where we’re headed with GNOME and KDE together, take a look at this blog post.
We also reviewed and evaluated compositing managers and desktop shells that we could use for a phone UI. We aim to use only Wayland, trying to get rid of as much X11 legacy as we possibly can, for performance issues and for better security. From our discussions with GNOME maintainers of existing compositors and shells, we may be better off igniting a new compositor (upstreamed and backed by GNOME) in order to avoid the X11 baggage.
On the application and middleware side of things, we have generated an impressive list of applications we could start to modify for the phone to reach the campaign goals and we have further narrowed down middleware stacks. We are still evaluating so I do not want to go into too much detail here, in order not set any expectation. We will of course talk about this in more detail in some later blog posts.
Meeting with Chip Makers
As the CPU choice is pretty clear lately, we are going to have a meeting with NXP and some other chip makers at Embedded World in Nürnberg, Germany, at the end of the month. This is very encouraging since we worked for months on getting a direct contact to NXP, which we now finally have and who we will meet in person at the conference. The search for design and manufacturing partners is taking longer than expected though. Our own hardware engineering team together with the software team, especially our low level and kernel engineers, started to create a hardware BOM (bill of material) and also a “floor plan” for a potential PCB (printed circuit board) layout, but it turns out that many manufacturers are reluctant to work with the i.MX 8M since it is a new CPU/SOC. We have, however, some promising leads and good contacts so we will work on that.
Purism Librem 5 team members attending FOSDEM
By the way, many Purism staff members will be at FOSDEM this week-end, on the 3rd and 4th of February. In addition to the design and marketing team, PureOS and Librem 5 team members will be there and we would love to get in touch with you! Purism representatives dedicated to answering your questions will be wearing this polo shirt so you can easily recognize them:
PureOS, a Free Software Foundation endorsed GNU distribution, is what Purism pre-installs on all Librem laptops (in addition to it being freely available for the public to run on their own compatible hardware or virtual machines). It comes with a GNOME desktop environment by default, and of course, since we love free ethical software, users can use KDE that is also available within PureOS. This is the future we will continue to advance across all our devices: a PureOS GNOME-first strategy, with other Desktop Environments (DEs), such as KDE, available and supported by Purism.
At Purism we want a unified default desktop environment, and considering that we have chosen GNOME to be the default on laptops, we hope to extend GNOME to also be the default on phones. The ability for users to switch is also very powerful, and having a strong, usable, and supported alternative—that is, KDE/Plasma—for the Librem 5 offers the best of the “unified default” world and the “usable user choice” worlds.
Symbiotic GNOME and KDE partnerships
Purism has partnered with both GNOME and KDE for the Librem 5; what this means simply is that users running PureOS on their Librem 5 will get the choice of a GNOME environment or a KDE/Plasma environment, and the user could always switch between the two, like what is already the case on computers running PureOS. Will there be other partnerships in the future? We imagine so, since we will be happy to support any and all ethical OSes, GNU distributions, and want to make sure that the future is bright for a non-Android-non-iOS world.
While the initial GNOME and KDE partnerships mean uplifting diversity at the top level (and greater choice for users), each have a slightly different developmental and support roadmap. The reason for this is pragmatic, since KDE is very far along with their “Plasma” mobile desktop environment, while GNOME is farther behind currently. Investing time and efforts to advance the status of mobile GNOME/GTK+, aligns with our longer-term goals of a unified default desktop environment for PureOS, offering a convenient default for users. Diversity is why we are supporting and developing both GNOME/GTK+ and KDE/Plasma.
- KDE: Purism is investing in hardware design, development kits, and supporting the KDE/Plasma community, and will be sharing all early documentation, hardware designs, and kernel development progress with the core KDE/Plasma developers and community.
- GNOME: Purism is investing the same in hardware design, development kits, and supporting the GNOME/GTK+ community as we are with the KDE/Plasma community. In addition, Purism is needing to lead some of the development within the GNOME community, since there is not a large community around an upstream-first GNOME/GTK+ for mobile yet.
Choice is good, redundancy is good, but those are ideal when there is minimal additional investment required to accomplish technological parity. Since Purism uses GNOME as the default desktop environment within PureOS on our laptops, we figured we are going to invest some direct development efforts in GNOME/GTK+ for mobile to stay consistent across our default platforms. Adding KDE as a second desktop environment is directly aligned with our beliefs, and we are very excited to support KDE/Plasma on our Librem 5 phone as well as within PureOS for all our hardware. We will support additional efforts, if they align with our strict beliefs.
Why not just use KDE/Plasma and call it a day?
If we were doing short-term planning it would be easy to “just use Plasma” for the Librem 5, but that would undermine our long-term vision of having a consistent look/feel across all our devices, where GNOME/GTK+ is already the default and what we’ve invested in. Supporting both communities, while advancing GNOME/GTK+ on mobile to allow it to catch up, aligns perfectly with our short-term goals (offering Plasma on our Librem 5 hardware for early adopters who prefer this option), while meeting our long-term vision (offering a unified GNOME stack as our primary technological stack across all our hardware). It is also a good way to give back to a project that needs our help.
Why not just push GNOME and GTK+ and forward?
Because having an amazingly built Plasma offering available early to test and ship to users is a superb plan in many ways—not just for redundancy, but also because KDE/Plasma also aligns so well with our beliefs. The product readiness across these two desktop environments are so different it is not easy to compare side-by-side.
Empowering both communities is possible
Overall, Purism is investing the same amount across hardware, boot loader, kernel, drivers and UI/UX. These are shared resources. The deviation boils down to:
- GTK+ and the GNOME “shell” development, that Purism is planning to be directly invested in, in close collaboration with upstream
- Community support: by being involved in both communities, we are effectively doubling our efforts on supporting those communities, but that is a small cost for the greater benefit of users.
Supporting both KDE/Plasma and GNOME means we will continue to build, support, and release software that works well for users across Purism hardware and within PureOS. Purism fully acknowledges that each platform is in different release states, and will be working with each community in the areas required—be that software development, hardware development kits donated, community outreach, conference sponsorship, speaking engagements, and offering product for key personnel.
Update/P.S.: for the GNOME side of things, we are in close collaboration with upstream GNOME, and have followed GNOME Shell maintainers’ recommendations to have a simpler, Wayland-only shell (“phosh”) developed. You can learn more about it in our 2018 March 3rd technical report, in the “Compositor and Shell” section. So rest assured, those decisions have been taken with the “blessing” of upstream, based on purely technical grounds.
First, let me apologize for the silence. It was not because we went into hibernation for the winter, but because we were so busy in the initial preparation and planning of a totally new product while simultaneously orienting an entirely new development team. Since we are more settled into place now, we want to change this pattern of silence and provide regular updates. Purism will be giving weekly news update posts regarding the Librem 5 phone project, alternating progress reports on two fronts:
- from the technology development point of view (the hardware, kernel, OS, etc.);
- from the design department (UI+UX), and our collaboration with GNOME and KDE.
To kickoff this new update process, today’s post will discuss the organizational and technological progress of the Librem 5 project since November 2017.
Just after our successful pre-order crowdfunding campaign (by the way, thank you to all of the backers!) we started to reach out to people who had applied for jobs related to the Librem 5 project. We had well over 100 applicants who showed great passion for the project and had excellent resumes.
Our applicants came from all over the world with some of the most diverse backgrounds I have ever seen. Todd Weaver (CEO) and myself did more than 80 interviews with applicants over a two weeks period. In the end, we had to narrow down to 15 people that we would make offers to; it was with great regret that we had to turn down so many stellar applicants, but we had to make decisions in a timely fashion and unfortunately the budget isn’t unlimited. During the weeks that followed, we negotiated terms with our proposed team members and started to roll new people into the team (with all that involves in an organizational setting). All of the new team members are now on board as of January 2018. They are not yet shown on our team page, but we will add them soon and make an announcement to present all the individuals who have recently joined our team.
As amazing as our community is, we also received applications from individuals who are so enthusiastic about our project that they want to help us as volunteers! We will reach out to them shortly, now that the core team is in place and settled.
There are so many people to thank for the successful jump start of our phone development project! It was amazing for us to see how much energy and interest we were able to spark with our project. We want to give a big thank you to everyone for reaching out to us and we really appreciate every idea and applicant.
CPU / System On Chip
During our early phase we used a NXP i.MX6 SOC (System On Chip) to begin software evaluation, and the results were pretty promising. This was why we listed the i.MX6 in the campaign description. The most important feature of the i.MX6 was that it is one of only a handful of SOCs supported by a highly functional free software GPU driver set, the Etnaviv driver. The Etnaviv driver has been included in the Linux mainline kernel for quite some time and the matching MESA support has evolved nicely. Briefly after our announcement we were contacted by one of the key driving forces behind the Etnaviv development effort which provides us with valuable insight in to this complex topic.
Further work with the i.MX6 showed us that it still uses quite a lot of power so when put under load it would drain a battery quickly, as well as warm up the device.
NXP had been talking about a new family of SOCs, the i.MX8, which would feature a new silicon processor and updated architecture. The release of the i.MX8 had been continuously postponed. Nevertheless, once we realized that the i.MX6 might be too power hungry, the i.MX8 became appealing to us. Hardware prototype operations are always tricky because you have to plan for emerging technologies that you meld with existing parts or materials. Components from original manufacturers sometimes never get released, are discontinued or the availability from the factory grinds to a halt for reasons beyond our control. This is the function of engaging in prototype development so that we can suffer the slings and arrows for you to provide the customer the best possible end product. We have been in active communication with all of our suppliers preparing a development plan that is beneficial for all of us.
At CES in Las Vegas, NXP announced the product release dates for their new SOC, the i.MX8M, along with a set of documentation. This is currently the most likely candidate we will use in the Librem 5. We are very excited about this timely announcement! At Embedded World in Nürnberg, Germany, NXP will announce details and a roadmap. We will be attending and discuss with NXP directly about the i.MX8M for the Librem 5.
We have also decided to use AARCH64, a.k.a. “ARM64”, for the phone software builds as soon as we have i.MX8 hardware. A build server for building ARM64 is now in place and the PureOS development team is beginning to work with the Librem 5 development team on the build process. Adding a second architecture for the FSF endorsed PureOS—that will run on Librem laptops as well as the Librem 5 phone—is a major undertaking that will benefit all future Librem 5 phone development.
Prototype Display for Development Boards
Since the i.MX8 is still not yet easily available, and in order not to unnecessarily slow development progress, we need similar hardware to start developing software. We switched to an i.MX6 Quad Plus board which should provide similar speed for the GPU to what we will find in the i.MX8M. From our contact from the Etnaviv developers we know that they are heavily working on the i.MX8M support so we can expect that Etnaviv will be working on it within the year.
One of the big tasks of our software and design teams, working with our partners (GNOME, KDE, Matrix, Nextcloud, and Monero), will be to create a proper User Interface (UI) and User Experience (UX) for a phone screen. The challenges are that the screen will be between 5″ to 5.5″ diagonally with a resolution of up to full HD (1920×1080), and a functional touchscreen! The amazing teams developing GNOME and KDE/Plasma have already done a great job laying the groundwork technologies and setting up this kind of interface to build, develop, and test with. With such great partners and development teams we are confident that we can successfully integrate the freedom, privacy, and security of PureOS with phone hardware to provide a beautiful user experience.
To help with development, we are already in the process of sourcing components to attach 5.5″ full HD displays to our development boards. Our development boards are already booting a mainline kernel into a Wayland UI nicely. We are evaluating similar displays from several manufacturers. We found a supplier for a matching adapter logic board (HDMI to MIPI). Our hardware engineer has already designed an additional adapter for interfacing the display’s touchscreen so that we will realistically have a 5.5″ full HD screen with touch capability on our development boards.
Potential Manufacturing Sites
The overall plan is to have a custom device manufacturing process setup somewhere where we can manufacture our own devices. Since November of last year we have been intensively researching and evaluating potential manufacturing partners. So far we have been in contact with over 80 potential fabricators and are in the process of negotiating capabilities and terms. No decision has been made yet. We have some promising prospects from all over the world, including Asia, Europe and the USA, and we plan on visiting some of these sites in person possibly by the end of February or March.
Now that the development team is in place we will be reaching out to our partners. Our UI/UX design team along with phone dev team are working with the GNOME UI/UX team to develop a path forward for mobile interfaces. We will also reach out to others who have partnered with us during the campaign, such as the KDE/Plasma team, Matrix, Nextcloud, Monero and many more.
I hope that the fog has been lifted, and we have answered questions you might have or assuaged fears of our silence. We hope that you enjoyed this first dive into our development process. We here at Purism are all very excited about the Librem 5 phone project, as we are passionate about all of our products, with the phone holding a special place in our hearts and those of the Free Software community. That’s what makes us different from companies rolling out “yet another Android phone”, swapping color palettes or removing headphone jacks under the guise of “innovation”…
See you next week for more news on the Librem 5 project!