Purism replies on CHIPSEC failures, adds TPM add-on, starts Heads work

Re: https://firmwaresecurity.com/2017/11/15/purism-librem15-fails-chipsec-security-tests/

Purism responds to the CHIPSEC failures here:


They also point out in that forum, and here:


that Purism is getting ready to start using Heads payload. They’ve been talking about it for months, maybe it’ll be a real option for upcoming Librem customers? I’m very excited to see a Heads system available by an OEM, instead of DIY and not an easy task.

And they’re adding a TPM as an ‘add-on’ to existing Librem laptops. Heads needs TPM for it’s measurements. (Hmm, I thought TPMs were an integral and tamper-resistant part of the system, and something that could be added on for trust was called a smartcard, but ok. I guess you have to solder the HW to the system. I presume attackers will be ordering spare add-ons so they can swap out units.)

In the above Purism forum, there was this user comment:

“I like the idea of putting a demo Librem notebook to a BlackHat conf where they try to break into the devices. Would be a nice test and a good commercial for you.”

They cannot do that with current Librem models. 🙂 This will need to wait for TPMs to be pre-installed and Heads as the payload.

This response from the above Purism forum seems a bit invalid:

“So there’s no way to access a BIOS menu to change the boot sequence (boot from USB) or set a machine password etc?”

“No, there is no such thing. The BIOS boots into your machine in roughly 450 milliseconds, there is no support for a menu, there is no time even for the user to press a key on the keyboard to enter a menu. The idea of coreboot is to do the minimum hardware initialization and then go to a payload. In our case, we use SeaBIOS which itself will initialize the video card and show the splash screen logo, and wait for 2 seconds for you to press ESC to show you the boot menu and let you choose your device (otherwise, it just boots to the default one). The boot choice isn’t saved, it’s just a boot override. If you want to change an option in coreboot, you need to change the config in the source and recompile coreboot then reflash it. If you want to change the boot order, you need to change the boot order in a file embeded in the flash, then reflash the BIOS.”

Yes, there is thing, which the reply says does not exist then a few sentences later explains that it does exist. The BIOS menu to change the boot order is available to anyone with physical access to the system, and presses the ESC key within 2 seconds of poweron. The unprotected BIOS and MBR-based hard drive can be quickly overwritten with malware on the attacker’s boot thumbdrive. Attendees of ‘a BlackHat conf’ will have such skills. 🙂

Purism is spending all their time undoing Intel’s features — Intel ME, Intel FSP, and now re-embracing older features — Intel TPM. Intel SMM is still an issue, STM is not being used by Purism. Intel ME may be disabled, but it’s a black-box device, who knows when attackers will start reactivating it and putting their malware-based version of Minix on that chip? You’re going to need tools to detect if ME is really disabled. I hope Purism’s roadmap has a RISC-V chip-based laptop in it, so they can stop fighting Intel features and have a fully-open stack. If they keep fighting the Intel stack, I hope they add the ‘stateless laptop’ that Joanna has proposed to their roadmap:


It might be useful to add coreboot Verified Boot to help secure their SeaBIOS payload, but that could probably only secure PureOS, and distro hoppers will have no benefit. But I don’t think Heads and Verified Boot are compatible? SeaBIOS also has TPM support, that’d be nice to see those measurements used, if they are embracing a TPM. And now that they have a TPM, they can start using Intel TXT too. 🙂

I am a little perplexed about Purims customer audience, who is concerned about privacy, and yet has so little concern for security, in exchange for the convenience feature of being easy to distro-hop. Anyway, if you want security, wait for the TPM and Heads to be integrated with future Librems.



Purism Librem15 fails CHIPSEC security tests

Current Purism Librem15 systems — based on Intel x64/coreboot/SeaBIOS tech — results in 3 FAILs and 1 WARNING from CHIPSEC:

The UEFI Forum recommends that OEMs pass CHIPSEC’s tests before shipping units to customers. I wish modern BIOS-based OEMs would also heed that advice… The default install is to use an MBR-based partition, so also be wary of all of the existing BIOS-centric, MBR-based rootkits. Adhere all ‘evil maid’ warning signs with this laptop. If you have corporate policies that require NIST 800-147/155/193 requirements, you might have to work hard to justify this device. I wish it were not true: configurable or secure, choose one.

In other computer review news: the trackpad did not work during initial install, had to be rebooted. I’m guessing trackpad drivers aren’t integrated? You’ll have to use external mouse if you need to click on something during install of Linux. Same with backlit key and display intensity features: only worked after OS setup. Firmware security pedantry aside, nice hardware. Fan rarely kicks in, unlike some OEMs. It is nice to see a Mac-style trackpad instead of a PC-style touchpad with 2 explicit button areas, I’ve grown to dislike those. Startup and poweroff are both very fast. Reminds me of what a modern non-UEFI system should be like. Great, except we’re no longer in a world where security can be ignored. If you want an insecure BIOS box, you’ll probably enjoy this system. If you care about security, this is a BIOS box….


Chipsec v1.3.4 released

New or Updated Functionality:
* Updated support for 7th/8th generation Intel processors
* Added ability to undefine a configuration entry
* Added HAL and utilcmd for TPM Event Log
* Added utilcmd for TPM commands
* Added support for Apollo Lake
* added utilcmd to inspect PCI command/control registers





Embedi: UEFI BIOS holes. So much magic. Don’t come inside.

24 October, 2017
UEFI BIOS holes. So Much Magic. Don’t Come Inside.
In recent years, embedded software security has become a red-hot topic, attracting the attention of high profile security researchers from all around the globe. However, the quality of code is still far from perfect as long as its security is considered. For instance, the CVE-2017-5721 SMM Privilege Elevation vulnerability in the firmware could affect such scope of vendors like Acer, ASRock, ASUS, Dell, HP, GIGABYTE, Lenovo, MSI, Intel, and Fujitsu. This white paper is intended to describe how to detect a vulnerability in a motherboard firmware with the help of the following tools: Intel DAL, UEFITool, CHIPSEC, RWEverything, and how to bypass the patch that fixes this vulnerability.[…]



CHIPSEC 1.3.3 released

ErikBjorge released this 2 days ago:

New or Updated Modules:
* Added common.spi_access to verify the host processor access rights for different SPI regions

New or Updated Functionality:
* Added ability to search a memory region of a string
* Updated support for the RWE driver

* Added error handling if a register type is not supported





CHIPSEC adds RWEverything support on Windows


“Use RWE/windows helpers when the corresponding driver is present.”

So, for any defending Windows systems, all of the CHIPSEC caution in WARNING.txt against the CHIPSEC HAL driver should also be applied to the RWEverything driver, “C:\Windows\System32\drivers\RwDrv.sys”.


RWEverything license excerpt:

This utility comes with ABSOLUTELY NO WARRANTY, it allows you to modify hardware settings, this may damage your system if something goes wrong. Author will not take any responsibility about that, you are on your own risk. This utility should not be used in commercial or consumer products.