What is the coreboot version of the Librem 16?

Hardware Librem 16
1

I added the Librem 16 to this table:

https://en.wikipedia.org/wiki/Librem#Comparison_of_laptops

But I do not know what the coreboot of the Librem 16 is. Where can I find that?

Also, it would not surprise me if the coreboot of the other Librem laptops in the above mentioned page is out of date.

2

It should be coreboot 26.03: https://source.puri.sm/firmware/releases/-/blob/master/changelog.md?ref_type=heads#coreboot-2603-purism-1-2026-06-12.

3

Maybe. Maybe not. Aren’t all Librem 16 laptops going to come with Pureboot? The Shop page doesn’t seem to offer a menu widget any more for choice of boot firmware (and hasn’t for some years).

4

Coreboot is part of PureBoot.

5

https://docs.puri.sm/Software/PureBoot/Overview.html

PureBoot is Purism’s cutting edge, complete secured boot process and combines a number of technologies, including:

Librem laptops came with coreboot pre-installed until November 2023. Librem computers since November 2023 come with PureBoot pre-installed.

6

Question: Pureboot 30.1 (latest release for Librem16) is rebased on coreboot 26.03.
It is the first new version of PureBoot in a very long time (2 years). So I currently have the former release 30, which was at the time based on coreboot 24.02. This release 30 was never rebased on upstream coreboot - but I guess it worked fine with no bugs that would have needed a firmware update. Now we have this new release 30.1, which essentially is for the new hardware (Librem 16) + this “Enable coreboot serial console on Librem 16 to work around XHCI controller disappearing on resume from S3” commit.
I have been considering flashing the new 30.1 release on my older KBL hardware - but what would I gain from doing that? I don’t care about the newer arch for the librem 16 - nor for the serial console problem on S3 resume…
But since release 30 was never rebased from coreboot 24.02 on, would I gain something if I were to flash the newer ROM with the more recent coreboot 26.03?

7

You will gain two major versions and one minor version.

8

Thank you! Funny, but not really helpful…
In fact, there was a precise reason why I was asking this question: I saw in a recent Dasharo/HEADS firmware update that they had implemented a new feature which locks down the BIOS region of the flash chip, making it immutable to the target OS. It involves configuring the SPI controller’s Protected Range registers (PR0 = Flash Descriptor, PR1 = BIOS, PR2 = CSME firmware/modules) by setting the WP bit (write protecting the range) in the specific register and then firing FLOCKDN bit in another SPI controller register. This entirely locks the PR registers (cannot change WP bit to disable) throughout the power on cycle. FLOCKDN (Flash Lock Down) can only be cleared by a hardware reset (power OFF → ON cycle) - not even S3 resume.
It seems that HEADS payload is firing FLOCKDN only when restricted boot is configured (config.user) - but the catch is that coreboot must have chipset_lockdown enabled, which is a Kconfig build-time option.
Hence my question if the new PureBoot Release 30.1 - rebased on upstream coreboot 26.03 - would actually implement this nice feature that makes the ROM immutable; whatever happens within the target OS cannot reflash the ROM and even the CPU cannot unlock that situation.

9

It sounds like what you are hinting at is that Dasharo Coreboot + Heads is a better fit for you.

10

I do use Dasharo coreboot/HEADS on a Nitropad laptop, and PureBoot on my Librems.
That is why I can compare their respective boot flow and payload’s scripts.
They are not very different, as they are both forks of upstream coreboot and Linuxboot: in their respective build systems, everything is the same and all the scripts, tools and modules are provided, it is only Kconfig and other board configurations that build a specific ROM for one or the other.
For example, if you look inside the payload’s initrd, the script that locks the chipset /bin/lock_chip is present in Pureboot as well - but the activation depends on some other coreboot Kconfig configuration.
This is why I was hoping the bump to coreboot 26.03 for the newer PureBoot Release 30.1 would maybe have activated that feature for locking the chipset just before handoff to the target OS.

11

After a deep investigation on my end to verify your claims against 3mdeb and Purism first, it looks like your concerns are validated:

KBL targets have not been updated in over two years, so to realign back on topic, we can look at the Librem 16 configuration:

L720-776:

# Security
#

#
# CBFS verification
#
# CONFIG_CBFS_VERIFICATION is not set
# end of CBFS verification

#
# Verified Boot (vboot)
#
CONFIG_VBOOT_LIB=y
# end of Verified Boot (vboot)

#
# Trusted Platform Module
#
CONFIG_TPM1=y
# CONFIG_TPM2 is not set
CONFIG_TPM=y
CONFIG_MAINBOARD_HAS_TPM1=y
# CONFIG_TPM_DEACTIVATE is not set
# CONFIG_DEBUG_TPM is not set
# CONFIG_TPM_MEASURE_MRC_CACHE is not set
# CONFIG_TPM_LOG_CB is not set
CONFIG_TPM_LOG_TPM1=y
# CONFIG_TPM_LOG_TPM2 is not set
CONFIG_TPM_MEASURED_BOOT_RUNTIME_DATA=""
CONFIG_PCR_BOOT_MODE=1
CONFIG_PCR_HWID=1
CONFIG_PCR_SRTM=2
CONFIG_PCR_FW_VER=10
CONFIG_PCR_RUNTIME_DATA=3
# end of Trusted Platform Module

#
# TCG storage
#
# CONFIG_TCG_OPAL_S3_UNLOCK is not set
# end of TCG storage

#
# Memory initialization
#
CONFIG_PLATFORM_HAS_DRAM_CLEAR=y
# CONFIG_SECURITY_CLEAR_DRAM_ON_REGULAR_BOOT is not set
# end of Memory initialization

CONFIG_INTEL_TXT_LIB=y
# CONFIG_INTEL_TXT is not set
# CONFIG_STM is not set
# CONFIG_INTEL_CBNT_SUPPORT is not set
CONFIG_BOOTMEDIA_LOCK_NONE=y
# CONFIG_BOOTMEDIA_LOCK_CONTROLLER is not set
# CONFIG_BOOTMEDIA_LOCK_CHIP is not set
# end of Security

Zero mention of CONFIG_INTEL_CHIPSET_LOCKDOWN as referenced in this GitHub issue:

So, time to answer your remaining questions:

Give Purism another ten years or so, you waited for a cosmetic upgrade after over two years, so you can certainly indefinitely wait for Purism to take your actual security concerns with generous lax.

Right, because bumping versions somehow equates to work being done towards your concerns.

12

Thank you for your investigation :+1:
I am surprised to see that even for the new Librem 16, this feature has not been implemented. I wonder why Purism would not align with other forks that implement thisFLOCKDNfeature: apparently, this is available on all recent Intel CPU arch, but also was on older SKL/KBL. There is nothing that would prevent Purism from implementing this security feature on all Librems from SKL era to latest CPUs - so why don’t they do this? What could be the reason holding back such an important security feature (there must be a reason, I can’t imagine they are simply not aware of it!)

13

Pardon my ignorance but why are these things all so nasty complicated? We have an interface for the OS to hack your BIOS, and then a lockdown setting to stop the OS from hacking your BIOS? Am I getting that right?

Why does any of this exist? I have a PC (not from Purism) which can dual boot both Windows and Linux, and what I see is that whenever I boot into Windows it goes into the BIOS settings and finds which ones it needs to change to make the separate independent Linux vNME chip no longer boot, and it toggles those, so then only Windows boots until I manually fix the BIOS settings myself in the BIOS menus. After every use of Windows.

These are virus designs. Having the operating system write to the BIOS is virus. Why are we doing this? Why is there an interface for virus and then a virus mitigation lockdown mode that we have to argue about enabling? What if we nuked all of these concepts out of the system and made a good system instead?

14

Why would they? There is no obligation for meaningful security in any of their products, so having any faith that they would prioritize it at all to begin with is a critical category error mixed with wishful thinking.

15

It is indeed complicated! And even more complicated to explain in understandable language.
I will give it a try.
The PureBoot stack is not at all the same as your regular PC with BIOS/UEFI firmware.
It is defense-in-depth boot stack which provides tamper evidence (but it is not tamper proof!) and the chain of trust is anchored into the bootblock of coreboot, the first stage executed after CPU comes out of reset. This approach is considered flawed by nature, because it is in fact the verifier (the bootblock) that verifies itself: if someone can forge the bootblock and the rest of the firmware in order to feed the TPM with all the right measurements in proper sequence to unseal the secret and have the LibremKey flash green (because both hotp-derived secrets match), then you are owned.
The only way to prevent this attack is to make the SPI flash ROM immutable - that is read-only, hardware-enforced by soldering the wp pin to ground and covering the flash chip with epoxy.
Unfortunately, this is not reversible and has for result that you can never again reflash the firmware, update the firmware, change policy settings, inject a gpg public key into the firmware - in fact your flash chip is now a real ROM that can’t be modified in any way.
This is very inconvenient! We don’t want that; no flexibility and if the firmware has a bug, it cannot be corrected with a new version: you can ditch your motherboard and buy a new one!
This is why developers are trying to devise a middle ground: not complete immutability but temporary hardware locked state enforced before launching the target OS and staying locked throughout the power cycle.
And this can be done now! This is what we were discussing: upstream coreboot and linuxboot (HEADS) have it available through Kconfig parameters at build time and a script lock-chip inside the payload runs just before handoff to the target OS, which actually puts the ROM in an immutable state until the laptop is powered off and on again.
Now, other manufacturers have implemented this great feature, but Purism hasn’t (although they could do it on all Librem laptops - just requires a little testing and a new build of PureBoot)
This would be a great security improvement and a real milestone - I don’t know why it has not been implemented yet - but maybe there are technical glitches/problems which we don’t know about.