Category: Additional Press Information

Intended for PR – used to filter out posts intended for the press

Trusted Platform Module now available as an add-on for Librem laptops

Over the past few months, we have been busy with a plethora of great projects being set afoot. We have been incrementally building a laptop inventory to ship from, we have been continuing the coreboot enablement work on our laptops, neutralizing—and then disabling—the Intel Management Engine, and launching our much awaited Librem phone campaign, which ended in a very motivating success—involving many great organizations part of the Free Software community, such as Matrix, KDE e.v., the GNOME Foundation, Nextcloud, and Monero.

It really has been a whirlwind of events, and this has been happening in parallel to us continuing our existing R&D and operations work, such as preparing a new batch of laptops—namely the much anticipated Librem 13 with i7 processor.

One particular security R&D project dear to our hearts has been the beginning of our collaboration with “Heads” developer Trammell Hudson, a project that has been quietly going on behind the scenes for the past few months. We are very pleased to announce today that we are making a positive step to make this effort within reach of early adopters, with the availability of a Trusted Platform Module (TPM) as an optional component for currently pending and near-future laptop orders. Read more

Deep dive into Intel Management Engine disablement

Starting today, our second generation of laptops (based on the 6th gen Intel Skylake platform) will now come with the Intel Management Engine neutralized and disabled by default. Users who already received their orders can also update their flash to disable the ME on their machines.

In this post, I will dig deeper and explain in more details what this means exactly, and why it wasn’t done before today for the laptops that were shipping this spring and summer.

The life and times of the ME

Think of the ME as having 4 possible states:

  1. Fully operational ME: the ME is running normally like it does on other manufacturers’ machines (note that this could be a consumer or corporate ME image, which vary widely in the features they ‘provide’)
  2. Neutralized ME: the ME is neutralized/neutered by removing the most “mission-critical” components from it, such as the kernel and network stack.
  3. Disabled ME: the ME is officially “disabled” and is known to be completely stopped and non-functional
  4. Removed ME: the ME is completely removed and doesn’t execute anything at any time, at all.

In my previous blog post about taming the ME, we discussed how we neutralize the ME (note that this was on the first generation, Broadwell-based Purism laptops back then), but we’ve taken things one step further today by not only neutralizing the ME but also by disabling it. The difference between the two might not be immediately visible to some of you, so I’ll clarify below.

  • A neutralized ME is a ME image which had most of its code removed.
    • The way the ME firmware is packaged on the flash, is in the form of multiple modules, and each module has a specific task, such as : Hardware initialization, Firmware updates, Kernel, Network stack, Audio/Video processing, HECI communication over PCI, Java virtual machine, etc. When the ME is neutralized using the me_cleaner tool, most of the modules will be removed. As we’ve seen on Broadwell, that meant almost 93% of the code is removed and only 7% remains (that proportion is different on Skylake, see further below).
    • A neutralized ME means that the ME firmware will encounter an error during its regular boot cycle; It will not find some of its critical modules and it will throw an error and somehow fail to proceed. However, the ME remains operational, it just can’t do anything “valuable”. While it’s unable to communicate with the main CPU through the HECI commands, the PCI interface to the ME processor is still active and lets us poke at the status of the ME for example, which lets us see which error caused it to stop functioning.
  • When the ME is disabled using the “HAP” method (thanks to the Positive Technologies for discovering this trick), however, it doesn’t throw an error “because it can’t load a module”: it actually stops itself in a graceful manner, by design.

The two approaches are similar in that they both stop the execution of the ME during the hardware initialization (BUP) phase, but with the ME disabled through the HAP method, the ME stops on its own, without putting up a fight, potentially disabling things that the forceful “me_cleaner” approach, with the “unexpected error” state, wouldn’t have disabled. The PCI interface for example, is entirely unable to communicate with the ME processor, and the status of the ME is not even retrievable.

So the big, visible difference for us, between a neutralized and a disabled ME, is that the neutralized ME might appear “normal” when coreboot accesses its status, or it might show that it has terminated due to an error, while a disabled ME simply doesn’t give us a status at all—so coreboot will even think that the ME partition is corrupted. Another advantage, is that, from my understanding of the Positive Technologies’s research, a disabled ME stops its execution before a neutralized ME does, so there is at least a little bit of extra code that doesn’t get executed when the ME is disabled, compared to a neutralized ME.

Kill it with fire! Then dump it into a volcano.

In our case, we went with an ME that is both neutered and disabled. By doing so, we provide maximum security; even if the disablement of the ME isn’t functioning properly, the ME would still fail to load its mission-critical modules and will therefore be safe from any potential exploits or backdoors (unless one is found in the very early boot process of the ME).

I want to talk about the neutralizing of the Skylake ME then follow up on how the ME was disabled. However, I first want you to understand the differences between the ME on Broadwell systems (ME version 10.x) and the ME on Skylake systems (ME version 11.0.x).

  • The Intel Management Engine can be seen as two things; first, the isolated processor core that run the Management Engine is considered “The ME”, and second, the firmware that runs on the ME Core is also considered as being “the ME”. I often used the two terms interchangeably, but to avoid confusion, I will from now on (try to) refer to them, respectively, as the ME Core and the ME Firmware, but note that if I simply say the ME, then I am probably referring to the ME Firmware.
  • The ME Firmware 10.x was used on Broadwell systems which had an ARC core, while the ME Firmware 11.0.x used on Skylake systems uses an x86 core. What this means is that the architecture used by the ME core is completely different (kind of like how PowerPC and Intel macs used a different architecture, or how most mobile devices use an ARM architecture, the Broadwell ME Core used an ARC architecture). This means that the difference between the 10.x and 11.0.x ME firmwares is major, and the cores themselves are also very different. It’s a bit like comparing arabic to korean!
  • As the format of the ME firmware changed significantly, it took a while to figure out how to decompress the modules and understand how to remove the modules without breaking anything else. Nicola Corna, the author of the me_cleaner tool, recently was able to add support for Skylake machines by removing all the non essential modules.

In my last ME-related post, I gave everyone a rundown of the modules that were in the ME 10.x firmware and which ones were remaining after it was neutered, so, for Skylake, here is the list of modules in a regular ME 11.0.x firmware:

-rw-r--r-- 1 kakaroto kakaroto 184320 Aug 29 16:33 bup.mod
-rw-r--r-- 1 kakaroto kakaroto  36864 Aug 29 16:33 busdrv.mod
-rw-r--r-- 1 kakaroto kakaroto  32768 Aug 29 16:33 cls.mod
-rw-r--r-- 1 kakaroto kakaroto 163840 Aug 29 16:33 crypto.mod
-rw-r--r-- 1 kakaroto kakaroto 389120 Aug 29 16:33 dal_ivm.mod
-rw-r--r-- 1 kakaroto kakaroto  24576 Aug 29 16:33 dal_lnch.mod
-rw-r--r-- 1 kakaroto kakaroto  49152 Aug 29 16:33 dal_sdm.mod
-rw-r--r-- 1 kakaroto kakaroto  16384 Aug 29 16:33 evtdisp.mod
-rw-r--r-- 1 kakaroto kakaroto  16384 Aug 29 16:33 fpf.mod
-rw-r--r-- 1 kakaroto kakaroto  45056 Aug 29 16:33 fwupdate.mod
-rw-r--r-- 1 kakaroto kakaroto  16384 Aug 29 16:33 gpio.mod
-rw-r--r-- 1 kakaroto kakaroto   8192 Aug 29 16:33 hci.mod
-rw-r--r-- 1 kakaroto kakaroto  36864 Aug 29 16:33 heci.mod
-rw-r--r-- 1 kakaroto kakaroto  28672 Aug 29 16:33 hotham.mod
-rw-r--r-- 1 kakaroto kakaroto  28672 Aug 29 16:33 icc.mod
-rw-r--r-- 1 kakaroto kakaroto  16384 Aug 29 16:33 ipc_drv.mod
-rw-r--r-- 1 kakaroto kakaroto  11832 Aug 29 16:33 ish_bup.mod
-rw-r--r-- 1 kakaroto kakaroto  24576 Aug 29 16:33 ish_srv.mod
-rw-r--r-- 1 kakaroto kakaroto  73728 Aug 29 16:33 kernel.mod
-rw-r--r-- 1 kakaroto kakaroto  28672 Aug 29 16:33 loadmgr.mod
-rw-r--r-- 1 kakaroto kakaroto  28672 Aug 29 16:33 maestro.mod
-rw-r--r-- 1 kakaroto kakaroto  28672 Aug 29 16:33 mca_boot.mod
-rw-r--r-- 1 kakaroto kakaroto  24576 Aug 29 16:33 mca_srv.mod
-rw-r--r-- 1 kakaroto kakaroto  36864 Aug 29 16:33 mctp.mod
-rw-r--r-- 1 kakaroto kakaroto  32768 Aug 29 16:33 nfc.mod
-rw-r--r-- 1 kakaroto kakaroto 409600 Aug 29 16:33 pavp.mod
-rw-r--r-- 1 kakaroto kakaroto  16384 Aug 29 16:33 pmdrv.mod
-rw-r--r-- 1 kakaroto kakaroto  24576 Aug 29 16:33 pm.mod
-rw-r--r-- 1 kakaroto kakaroto  61440 Aug 29 16:33 policy.mod
-rw-r--r-- 1 kakaroto kakaroto  12288 Aug 29 16:33 prtc.mod
-rw-r--r-- 1 kakaroto kakaroto 167936 Aug 29 16:33 ptt.mod
-rw-r--r-- 1 kakaroto kakaroto  16384 Aug 29 16:33 rbe.mod
-rw-r--r-- 1 kakaroto kakaroto  12288 Aug 29 16:33 rosm.mod
-rw-r--r-- 1 kakaroto kakaroto  49152 Aug 29 16:33 sensor.mod
-rw-r--r-- 1 kakaroto kakaroto 110592 Aug 29 16:33 sigma.mod
-rw-r--r-- 1 kakaroto kakaroto  20480 Aug 29 16:33 smbus.mod
-rw-r--r-- 1 kakaroto kakaroto  36864 Aug 29 16:33 storage.mod
-rw-r--r-- 1 kakaroto kakaroto   8192 Aug 29 16:33 syncman.mod
-rw-r--r-- 1 kakaroto kakaroto  94208 Aug 29 16:33 syslib.mod
-rw-r--r-- 1 kakaroto kakaroto  16384 Aug 29 16:33 tcb.mod
-rw-r--r-- 1 kakaroto kakaroto  28672 Aug 29 16:33 touch_fw.mod
-rw-r--r-- 1 kakaroto kakaroto  12288 Aug 29 16:33 vdm.mod
-rw-r--r-- 1 kakaroto kakaroto  98304 Aug 29 16:33 vfs.mod

And here is the list of modules in a neutered ME :

-rw-r--r-- 1 kakaroto kakaroto 184320 Oct  4 16:21 bup.mod
-rw-r--r-- 1 kakaroto kakaroto  73728 Oct  4 16:21 kernel.mod
-rw-r--r-- 1 kakaroto kakaroto  16384 Oct  4 16:21 rbe.mod
-rw-r--r-- 1 kakaroto kakaroto  94208 Oct  4 16:21 syslib.mod

The total ME size dropped from 2.5MB to 360KB, which means that 14.42% of the code remains, while 85.58% of the code was neutralized with me_cleaner.

The reason the neutering on Skylake-based systems removed less code than on Broadwell-based systems is because of the code in the ME’s read-only memory (ROM). What this “ROM” means is that a small part of the ME firmware is actually burned in the silicon of the ME Core. The ROM content is the first code executed, loaded internally from the ROM, by the ME core, and it has the simple task of reading the ME firmware from the flash, verifying its signature, making sure it hasn’t been tampered with, loading it in the ME Core’s memory and executing it.

  • On Broadwell, there is about 128KB of code burned in the ME Core’s ROM. That 128KB of code contains the bootloader as well as some system APIs that the other modules can use.
  • On Skylake, the ROM code was decreased to 17KB, leaving only the basic bootloader, and moving the system APIs to a module of their own inside the ME firmware.
  • This means that the total amount of code remaining, including the ROM is 360+17KB out of 2524+17KB = 377/2541 = 14.84% for Skylake, while on Broadwell, it’s 120 + 128KB out of 1624+128KB = 248/1752 = 14.15% of code remaining. The difference is much smaller now when we account for the code hidden in the ROM of the processor.

The problem with the code in the ROM is that it cannot be removed because it’s inside of the processor itself and, well, it’s Read-Only Memory—it cannot be overwritten in any way, by definition. On the bright side, it is nice to see that most of the code that was previously in the ROM has now been moved to the flash in Skylake systems.

The ME firmware itself has multiple “partitions”, each containing something that the ME firmware needs. Some of those partitions will contain code modules, some will contain configuration files, and some will contain “other data” (I don’t really know what). Either way, the ME firmware contains about a dozen different partitions, each for a specific purpose, and two of those partitions contain the majority of the code modules.

Schrödinger’s Wi-Fi

I’ll now explain what has been done to get to this point in the project. When I was done with the coreboot port to the new Skylake machines, I tried to neutralize the ME, thinking it would be a breeze, since me_cleaner claimed support for Skylake. Unfortunately, it wasn’t working as it should and I spent the entire hacking day at the coreboot conference trying to fix it.

The problem is that once the ME was neutralized with me_cleaner, the Wi-Fi module on the Librem was unpredictable: it sometimes would work and sometimes wouldn’t, which was confusing. I eventually realized that if I reboot after replacing the ME, the wifi would keep the same state as it was in before:

  • if I neutralized the ME and reboot, it would still work, but after powering off the machine and turning it on, the wifi would stop working;
  • if I restored a full ME (instead of a neutralized one) and rebooted, the wifi would remain dead;
  • …but if I power off the machine and turn it back on, the wifi would finally be restored.

I figured that it has something to do with how the PCI-Express card is initialized, and I spent quite some time trying to “enable it” from coreboot with a neutralized ME. I’ll spare you the details but I eventually realized that I couldn’t get it to work because the PCIe device completely ignored all my commands and would simply refuse to power up. It turns out that the ME controls the ICC (Integrated Clock Controller) so without it, it would simply not enable the clock for the PCIe device, so the wifi card wouldn’t work and there is nothing you can do about it because only the ME has control over the ICC registers. I tried to test a handful of different ME firmware versions, but surprisingly, the wifi module never worked on any of those images, even when the ME was not neutralized. Obviously, it meant that the ME firmware was not properly configured, so I used the Intel FIT tool (which is used to configure ME images, allowing us to set things like PCIe lanes, and which clocks to enable, and all of that). Unfortunately, even when an image was configured the exact same way as the original ME image we had, the wifi would still not work, and I couldn’t figure out why.

I shelved the problem to concentrate on the release of coreboot and eventually on the SATA issues we were experiencing. The decision was made to release the Librem 13 v2 and Librem 15 v3 with a regular ME until more work was done on that front, because we couldn’t hold back shipments any longer (and because we can provide updates after shipment). Also note that at that time, the support for Skylake in me_cleaner was very rough—it was removing only half of the ME code because the format of the new ME 11.x firmware wasn’t fully known yet.

A few weeks later, I saw the release of unME11 from Positive Technologies and a week later, Nicola Corna pushed more complete support for Skylake in a testing branch of me_cleaner. I immediatly jumped on it and tested it on our machines. Unfortunately, the wifi issue was still there. I decided to debug the cause by figuring out what me_cleaner does that could be affecting the ME firmware that way.

As I mentioned earlier in this post, the ME firmware is made up of a dozen of partitions, some of those containing code modules, and me_cleaner will remove all the partitions except one, in which it will remove most of the modules and leave only the critical modules needed for the startup of the system. Therefore, I started progressively whitelisting more modules so me_cleaner wouldn’t remove them, and testing if it affected the wifi module. This was annoying to test because I’d have to change me_cleaner, neutralize the ME firmware, then copy the image from my main PC to the Librem then flash the new image, poweroff, then restart the machine, and if the Wifi wasn’t working, which was 99% of the time, I had to copy the files through a USB drive. I eventually restored all of the modules and it was still not working, which made me suspect the cause might be in one of the other partitions, so I gradually added one partition at a time, until the Wifi suddenly worked. I had just added the “MFS” partition, so I started removing the other partitions again one at a time, but keeping the “MFS” partition, and the Wifi was still working. I eventually removed all of the code modules (apart from the critical ones) but keeping the MFS partition, and the wifi was still working. So I had found my fix: I just need to keep the “MFS” partition in the image and the wifi would work.

So many firmwares, so little time

So, what is this mysterious “MFS” partition? There’s not a lot of information about it anywhere online, other than one forum or mailing list user mentioning the MFS partition as “ME File System”. I decided to use a comparative approach.

The fun thing  when comparing ME firmware images: not only are there multiple versions (ex: 10.x vs 11.x), for each single ME version there are multiple “flavors” of it, such as “Consumer” or “Corporate”, and there are also multiple flavors for “mobile” and “desktop”.

  • When I extracted and compared all the partitions of all the variants and flavors, the only difference between a mobile and a desktop image is in the MFS partition, as every other partition shares the same hash between two flavors of the same version.
  • I then compared the various partitions between a configured and a non configured ME firmware, and noticed that what the Intel FIT tool does when you change the system’s configuration is to simply write that configuration inside of the MFS partition.
  • This means that the MFS partition, which doesn’t contain any code modules, is used for storage of configuration files used by the ME firmware. This is somewhat confirmed by the fact that the MFS partition is marked as containing data.

After modifying me_cleaner to add support for the Librem, which allows us to neutralize the ME while keeping the Wifi module working, I discussed with Nicola Corna how to best integrate the feature into me_cleaner. We came to the conclusion that having a new option to allow users to select which partitions to keep would be a better method, so I sent a pull request that adds such a feature.

Unfortunately, while the wifi module was working with this change, I also had an adverse side-effect when adding the MFS partition back into the ME firmware: my machine would refuse to power off, for example, and would have trouble rebooting.

  • The exact behavior is that if I power off the machine, Linux would do the entire power off sequence then stop, and I would have to manually force shutdown the Librem by holding the power button for 5 seconds. As for the rebooting issue, instead of actually rebooting when Linux finishes its poweroff sequence, the system will be frozen for a few seconds before suddenly shutting itself down forcibly, then turning itself back on 5 seconds later, on its own. This isn’t the most critical of issues, but it would be very annoying to users, and unfortunately, I couldn’t find the cause of this strange behavior. All I knew was that if I remove the MFS partition, coreboot says the ME partition is corrupted, and the wifi module doesn’t work, and if I keep the MFS partition, coreboot says the ME partition is valid, the wifi module works, but the poweroff/reboot issues automatically appear.
  • The solution for these issues turned out to be unexpectedly simple. After another of our developers said he was ready to live with the poweroff/reboot issues, and I sent him a neutralized ME for his system, I was told that his machine was working fine with no side-effects at all. I didn’t know what the difference between his machine and mine was, other than the fact that my machine is a prototype and his was a “production” machine. I then tested my neutralized ME on the “production” Librem 13 unit I had on hand, and I didn’t have any side effects of the neutralizing of the ME firmware. I then updated my coreboot build script to add the neutralization option and asked users on our forums to test it, and every one who tested the neutralized ME reported back success with no side-effects. I then realized the problem is probably only caused by the prototype machine that I was using. Well, I can live with that.

Disabling the ME

The next step for me was to start reverse-engineering the ME firmware, like I had done before. This is of course a very long and arduous process that took a while and for which I don’t really have much progress to show. One thing I wanted to reverse-engineer was the MFS file system format so I could see which configuration files are within it and to start eliminating as much from it as possible. I started from the beginning however, by reverse engineering the entry point in the ROM. I will spare you much of the detail and the troubles in trying to understand some of the instructions, and mostly some of the memory accesses. The important thing to know is that before I got too far along, Positive Technologies announced the discovery of a way to disable the Intel ME, and I needed to test it.

Unfortunately, enabling the HAP bit which disables the ME Core, didn’t work on the Librem: it was causing the power LED to blink very slowly, and nothing I could do would stop it until I removed the battery. I first thought the machine was stuck in a boot loop, but it was just blinking really slowly. I figured out eventually that the reason was that the “HAP” bit was not added in version 11.0.0, but rather in version 11.0.x (where  x > 0). I decided to try a newer ME firmware version and the HAP bit did work on that, which confirmed that the ME disablement was a feature added to the ME after the version the Librem came with (11.0.0.1180). So now I have a newer ME (version 11.0.18.1002) that is disabled thanks to the HAP bit, but… no Wi-Fi again.

I decided to retry using the FIT tool to configure the ME with the exact same settings as the old ME firmware. I went through every setting available to make sure it matches, and when I tried booting it again, the ME Core was disabled and the Wifi module was working. Great Success!

Obviously, I then needed to do plenty of testing, make sure it’s all working as it should, confirm that the ME Core was disabled, test the behavior of the system with a ME firmware both disabled and neutralized, and that it has no side effects other than what we wanted.

My previous coreboot build script was using the ME image from the local machine, but unfortunately, I can’t do that now for disabling the ME since it’s not supported on the ME image that most people have on their machines. So I updated my coreboot build script to make it download the new ME version from a public link (found here), and I used bsdiff to patch the ME image with the proper configuration for the WiFi to work. I made sure to check that the only changes to the ME image is in the MFS partition and is configuration data, so the binary patch does not contain any binary code and we can safely distribute it.

Moving towards the FSP

The next step will be to continue the reverse-engineering efforts, but for now, I’ve put that on hold because Positive Technologies have announced that they found an exploit in the ME Firmware allowing the executing of unsigned code. This exploit will be announced at the BlackHat Europe 2017 conference in December, so we’ll have to wait and see how their exploit works and what we can achieve with it before going further. Also, once Positive Technologies release their information, it might be possible for us to work together and share our knowledge. I am hoping that I can get some information from them on code that they already reverse engineered, so I don’t have to duplicate all of their efforts. I’d also like to mention that, just as last time, Igor Skochinsky has generously shared his research with us, but also getting data from Positive Technologies would be a tremendous help, considering how much work they have already invested on this.

Right now, I have decided to move my focus to investigating the FSP, which is another important binary that needs to be reverse-engineered and removed from coreboot. I don’t think that anyone is currently actively working on it, so hopefully, I can achieve something without duplicating someone else’s work, and we can advance the cause much faster this way. I think I will concentrate first on the PCH initialization code, then move to the memory initialization.

GNOME & KDE: The Purism Librem 5 phone is building a shared platform, not walled gardens

You might have heard about our Librem 5 phone campaign that we recently launched and that has now crossed the $300,000 milestone. If you are reading this particular blog post, it is quite probably because you are a member of the great GNOME/KDE/freedesktop community, and if you were expecting the Librem 5 to be only “a GNOME phone” and exclusionary of others you will be happy to know that Purism is working with both KDE e.V. and the GNOME Foundation, and will continue to do so.

As a matter of fact, to the question “Will you be running GNOME, Plasma, or your own custom UI?”, our campaign page’s FAQ stated, from the beginning:

“We will be working with both GNOME/GTK and KDE/Plasma communities, and have partnered with the foundations behind them for the middleware layer. PureOS currently is GNOME-based and our great experience with working with GNOME as an upstream as well as GNOME’s OS and design-centric development model; however we will also test, support, and develop with KDE and the KDE community, and of course we will support Qt for application development. We will continue to test GNOME and Plasma, and should have a final direction within a month after funding success. Whatever is chosen, Purism will be working with both communities in an upstream-first fashion.”

As a point of clarification, Purism is supporting GNOME/GTK and will continue to do so; Purism is also supporting KDE/Plasma and will continue; forming partnerships with these great communities is a way to establish our long-term commitment to those goals.

Likewise, Purism will ship PureOS by default on the Librem 5, but will support and work with other GNU/Linux distributions wishing to take advantage of this device.

The Librem 5 is about users reclaiming their rights to freedom, privacy and security on their mobile communication devices (also known as pocket computer, smartphone, etc.) with a platform that they love and trust. It is not about creating walled gardens, erecting barriers and division in the free desktop community, and reigniting the Desktop Wars of the past:

We are planning to empower users to run both GNOME, KDE, or whatever they see fit, on their GNU+Linux phone—just like we can have both GNOME and KDE on the same desktop/laptop today. The fact that we are going to be making an integrated convenient product that may or may not be a vanilla or heavily modified version of one of these two desktops as the “official recommended turnkey product choice for customers” takes away nothing from the value of these environments or from the ability to run and tinker with whatever Free and Open-Source software you see fit on your device—a device that you can truly own.

What we are providing here is a reference platform that is not Android, for both GNOME and KDE communities—we just so happen to need to provide it as a turnkey usable product for less tech-savvy customers as well, while doing it 100% in the open, upstream-first, like a true Free Software project should be. Right now, the exact set of software technologies we will base our “integrated product” on—whether closely based on KDE, or GNOME—is something we are still evaluating and will decide along the way. There is no “us” vs “them” here. The two projects are in different states of advancement when it comes to mobile and touch technologies, and both communities have their specificities, expertise, and strengths. No matter which project we pick as the basis to invest most of our technical resources in, both projects will win:

  • Even if one project is not chosen as the reference product user interface, it gains a hardware reference platform that community members can standardize on, and thus improve itself however they see fit.
  • This is not the nineties. GNOME and KDE have had a healthy collaboration relationship for the better part of a decade now!
  • We light up a competitive fire again in the hearts of contributors in both communities—and beyond. We can now fight for a platform we truly own, from the backend and middleware to the graphical user interface. No more proprietary UIs, no more “fork everything in middleware!”
  • We will still provide support to developers and testers across the board, everybody is welcome.

From a higher perspective, we believe this campaign is vital to the relevance of Free Software and the viability of GNU+Linux (vs Android+Linux) beyond the desktop, and to protect ourselves from pervasive surveillance and data capitalism. We hope you will see it in this light as well.

Of Laptops and Phones

On Thursday, we have revealed our plans to build the world’s first encrypted, free/libre and open platform smartphone that will empower users to protect their digital identity in an increasingly unsafe mobile world. This naturally comes after having announced the general availability and inventory of our Librem 13 and Librem 15 laptops in June this year. Our newest line of laptops are undergoing shipping after a short delay related to finishing our coreboot porting work (look forward to our technical update on this subject, to be published this Tuesday).

In preparation for the phone project, in addition to our regular work we have spent 18 months of R&D to test hardware specifications and engage with one of the largest phone fabricators, and have now reached the point where we are launching the crowdfunding campaign to gauge demand for the initial fabrication order and add the features most important to users.

Enabling the next generation of cable-cutters, we are making the Librem 5 the first ever Matrix-powered smartphone, natively using end-to-end encrypted decentralized communication in its dialer and messaging app. We will also offer regular baseband functionality separated off from the CPU, and work towards the goal of freeing all components.

As increasing concern among Android and iOS users grow around personal data they give up through WiFi connections, application installations and basic location services, we hope to address those concerns by manufacturing phones that will operate with free/libre and open source software within the kernel, the operating system, and all software applications. We have built our reputation within the GNU/Linux community on creating laptops designed to specifically meet user concern about digital privacy, security, and software freedom.

Starting at $599—less than the cost of many popular smartphones—and featuring a bona fide GNU/Linux operating system (PureOS) instead of Android or iOS, the Librem 5 is intended to give users unprecedented control and security with features unavailable on any other mainstream smartphone, including:

  • Make encrypted calls that mask your phone number
  • Encrypt texts and emails
  • Set up VPN services for enhanced web browsing protection
  • Use the phone on any 2G/3G/4G, GSM, UMTS, or LTE network
  • Edit or develop on the source code, which will be made publicly available, as a community-oriented FLOSS project (not “read-only open-source”)
  • Run PureOS or most modern GNU+Linux distributions—not yet another Android-based phone!
  • Enable hardware kill switches for the camera, microphone, WiFi/Bluetooth and baseband

Visit the Librem 5 crowdfunding campaign on our online shop to back the phone project!

Additionally, we will soon be posting a progress update on our laptop enablement coreboot work. Stay tuned for Youness’ technical report on Tuesday!

Guest Post: Why I Bought a Librem Laptop for my Daughter

I bought a Librem 13 for my 12 year-old daughter and couldn’t be happier about it. She wanted a new computer; and I, like a lot of parents, wanted to get something that is the best for her, but also offers some safety features, security from all these hacking threats, and that would give me peace of mind that my daughter was as safe as possible online.

There are probably a lot of reasons to buy a Librem laptop that are technically good choices, but I am a parent, not a developer. What drew me to the Librem 13 laptop was simple; it allowed me to have a computer that I felt was least likely to fall victim to ransomware, that offered the camera to be disabled, and that had a browser with privacy protection built-in. My daughter could simply open up the laptop, and I knew she was as protected as possible.

I considered numerous laptops from many companies, but making my laptop choice came down to two things, safety, and convenience. After receiving the Librem 13 laptop, my daughter has been happy to have a computer of her own that works for what she needs, I am happy it was easy for her to use, but most importantly I am happy that it gave me peace of mind that she is as safe as can be.

I highly recommend Purism to my family, my friends, and my coworkers, which at the end-of-the-day is probably the best endorsement of them all.

— Mike Morgan

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.

A fleet of coreboot laptops assembles

Following up on our status update where we revealed the imminent shipping date and general availability of our laptops this June, we’re happy to let you know today that we’ve recently had a breakthrough in our work to port the new laptops to coreboot, thanks to the fruitful collaboration between our coreboot developer Youness “KaKaRoTo” Alaoui and Matt “Mr. Chromebox” DeVillier (to whom we sent a prototype unit). Our coreboot port is now working for both the Librem 13 v2 and the Librem 15 v3, with all the test cases passing.

We are now pretty confident that we should be able to have coreboot firmware ready in time for factory preloading of the new inventory we’ll be shipping from in June. As we receive the first “production” units, we will ship some of those across the border, so that Youness can re-test and finalize the port on those machines (the results should be the same, but we want to make sure everything is top-notch). I will also seize the opportunity to take good reference images in our photo studio.

In the meantime, Youness is currently busy preparing his code contributions to be upstreamed officially to the coreboot project, after which he will be attending the 2017 edition of the coreboot conference in Denver. You will also soon be able to read his latest technical findings as part of the current round of coreboot ports.

The only model that will remain to be ported to coreboot afterwards will be the Librem 15 v2 (it turns out that the “v1” was an early demonstration unit that was sent out to some reviewers but never made it into large-scale production, so it does not actually need to be ported), thus reaching a milestone and honouring a promise that many of you have been eagerly looking forward to. That remaining port should be fairly straightforward to do, now that Youness has gained a lot of experience with other models. Then, depending on how the timing plays out this summer, our reverse engineering work is expected to resume from where we left off.

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.