How to update coreboot offline

So you are proposing that we create a service where we send coreboot and pureboot images in a USB via post?

For Pureboot you can download the *.rom and update it with a USB from Pureboot it self. Coreboot does not support that

Not at all; I said “bootable iso”, not bootable USB. I propose that Purism makes an ISO image that can be used to reflash Coreboot and Libreboot. This image should contain everything needed, not just a download script. No Internet should be required.

One would download it, use dd (or whatever) to create the bootable USB stick and just boot from it…

1 Like

so in addition to generating firmware update images, and maintaining the coreboot utility script to distribute and flash them, you want us to generate a new ISO for every firmware release? That seems impractical, especially since there are non-Librem users of PureOS, and so we’d need ISOs without firmware updates for them as to not cause havok.

The simple “offline” solution is a live USB and the current firmware image for your device, downloaded from our repo, and flashed manually with flashrom. You could have a separate USB with flashrom and a bash script to unpack and flash the image.

I don’t think you understood me. I am not asking to make an image of PureOS for every firmware update. I am asking to make an ISO image specifically for the firmware update, not containing a full operating system. It would greatly help everyone who is not using PureOS on a Librem.

but what would that entail? PureOS + flashrom + a bash update script really. Having to maintain another ISO image, regardless of what it contains or doesn’t, is an additional burden on the PureOS team. And having to ensure that OS image contains the latest flashrom and any other dependencies adds to that.

It would probably be better to simply keep the coreboot utility script on USB, use it to download the image to update, then boot PureOS live USB and use it to flash the already-downloaded update (which it should do, since it checks the archive hash before re-downloading, IIRC)

Ok, it would indeed require some additional work from the Purism team. But right now I do not even understand how I can do this myself.

Do you have a more detailed instruction how I can do it? How can I flash PureOS on a USB stick and have the firmware on the same stick at the same time? How should I modify the script so it does not try to go online?

You would need a live USB with persistent storage to do that; I don’t believe that’s something we provide instructions for, but I can see if there’s a quick/dirty way to do so

I’ll also need to double check if my recollection on the script is correct, or if I need to modify it to do so

If all you want to do is flashrom then you don’t really need to use PureOS to do the flashing, in which case you can use any distro that does support persistence out-of-the-box - and perhaps, in addition, some other distro already provides instructions for building custom Live boots.

Maybe it would also work to use two USB sticks (as is already suggested above). So the fixed stick contains whatever Live boot environment is best for this (and doesn’t need to change particularly often) and the variable stick contains the latest firmware, downloaded previously, for offline flashing. In that case, the variable stick doesn’t require complex setup. It just needs to contain a few files (hopefully).

Another reason a person might want to do an offline flash is for an airgapped computer.

one noteworthy limitation of simply downloading the files from our repo and flashing manually is that the the device serial number won’t be persisted, and the bootorder will be the factory default (NVMe, m.2 SATA, 2.5" SATA, external devices).

2 Likes

I am not sure I understand. Do I need the Internet to keep the serial number? It does not sound logical to me. What is the technical difference between the OS I boot from the hard drive and OS I boot from a USB stick? Both should have access to the same information (such as the serial number).

Using two USB sticks is of course a possibility, but it also forces me to trust two USB sticks instead of one. If we are talking about security, we should care about the USB attacks: https://blog.invisiblethings.org/2011/05/31/usb-security-challenges.html. It’s also more inconvenient, which does not help users to be secure at all.

I am slightly disappointed in the approach of Purism to security concerning the Coreboot flashing. Their approach to the security of Pureboot with the Librem Key is much more serious. My expectation from the security-oriented Purism company is that such questions should be prioritized and not result in replies like “it’s too much work”. Concerning work, shouldn’t it be just creating one bootable PureOS and never update it? Only the Coreboot script on it is to has to be updated, which is already mostly done anyway.

I even think that ordinary PureOS users should update their Coreboot using the offline method, too, since any compromise of the operating system may result in a compromise in the Coreboot.

Is there anyone who could help me to update my Coreboot without relying on non-updated operating system connected to the Internet?

You don’t have to use PureOS for it. You can use any Linux distro.

Dependencies for running this script are broken into 3 categories:

  • “base” - needed regardless of script function used
  • “flashrom” - needed to compile flashrom from source (if needed)
  • “coreboot” - needed to compile coreboot toolchain and coreboot itself

On a PureOS/Debian/Ubuntu-based distro, the dependencies are as follows; other distros may use slightly different packages/names

base: dmidecode wget coreutils gzip
flashrom: [base] + git build-essential libpci-dev libudev-dev zlib1g-dev
coreboot: [flashrom] + gnat m4 bison flex libncurses5-dev

If apt is detected on the system, the script will attempt to automatically install needed dependencies based on the function selected by the user.

mkdir ~/updates 
cd ~/updates 
wget https://source.puri.sm/coreboot/utility/raw/master/coreboot_util.sh -O coreboot_util.sh 
sudo bash ./coreboot_util.sh

If you’re extremely worried about a non updated OS, why not go with a Debian testing live ISO image (regenerated weekly)?

1 Like

you’re oversimplifying the argument significantly, and no Purism can’t simply build a single ISO that never needs to be updated. How would future devices be handled? One can’t simply boot a year-old PureOS 9 ISO with a year-old version of flashrom and expect to be able to flash the upcoming Librem 14 (eg).

One doesn’t need to be connected to the internet to flash the coreboot update, it just makes everything simpler since dependencies to build/flash vary depending on the underlying OS, flashrom may need to be built from source, etc.

2 Likes

Yes, but it also make everything much less secure. Consider the attacks on the WiFi stack, with CVEs every other month. Only Qubes OS defends from such attacks (by having a separate networking VM).

But if I am using a Purism laptop, I cannot securely update my Coreboot. The Purism’s approach to Coreboot updates makes my whole system vulnerable. Moreover, I have to use a liveUSB, which is not frequently updated, with known old vulnerabilities, and connect it to the Internet. This turns articles like this into a lie.

If Purism does not have resources to support such use case, I can understand this. Purism is already doing a lot of great stuff, which I appreciate. But you should accept that people who value security have such problem and think whether something can be done, or ask for a help of the community.

Edit: Actually, users of any other OS will have such problem with the vulnerable liveUSB, not just users of Qubes OS. However, in the latter such threat model is explicitly in the design.

how does booting a live USB to download a firmware update make your system less secure?

I’ve yet to hear a reasonable solution proposed. All I’m hearing is “Purism should publish a live USB with the latest firmware available offline every time an update is released.”

The problem is in the “download”, i.e., connecting a vulnerable insecure system to the Internet. The WiFi device has a vulnerable old driver/firmware and a full access to RAM via DMA attack. It can probably be attacked by a nearby WiFi access point, or any device nearby. See also this. Also, all USB devices in the laptop get access to the system and to the Internet, which is a problem. Qubes OS trusts neither PCI, nor USB devices by default.

I guess @Kyle_Rankin knows the details of the threat model better, since he is using Qubes OS himself.

Actually, even users of Librem 14 with PureOS would benefit from an offline update of the Coreboot. Normally, the kill switch does not allow to update the Coreboot. It means, even on a vulnerable system, your Coreboot should be safe. You boot a (trusted) USB stick, update the Coreboot and can be sure that nothing is compromised.

Are Coreboot updates released very often? Couldn’t you “just” replace all download actions in your update script by an equivalent, which takes the files from a local folder?

unless we’re mailing you a USB with the update, some sort of download is needed, whether it’s a Live ISO with the files, or a script which pulls everything dynamically. It would be great if we could update from within Qubes, that’s just not feasible at the moment.

The past 12 months has seen 8 coreboot releases and 7 Pureboot releases. I update as often as needed to address issues, provide microcode updates, etc.

An as I’ve explained before, the update script already works this way for the precompiled update option – if the files exist locally, and the hashes match, then no download of the firmware update is necessary.

But the mini v2/L14 also need a newer version of flashrom than is packaged in either Debian or PureOS (or any distro, because there’s not a tagged release which supports the platform). So either PureOS needs to package/distribute a non-tagged version of flashrom (which is logistically problematic, unless we fork it), or as is done currently, we download and build from source from a known good commit hash.

1 Like

The rest of my message is important, too. On Qubes, I can download an .iso (and write it to a USB stick) without involving the WiFi device, or full access to the Internet (from a firewalled trusted VM, which never ever ran any software before). I can even use a minimal VM with the smallest possible number of packages, greatly decreasing the attack surface. Moreover, I can independently verify the .iso using a different offline VM.
In principle, this whole thread is about decreasing the attack surface.

Thanks for the info, it is indeed more than I expected.

Qubes OS allows to securely install OS packages even in offline VMs (via TemplateVMs, which are also offline).

This means, we are not very far from a possibility to apply the Coreboot updates securely. We only need to add files and packages to the PureOS live .iso, right? If Purism cannot do it once a month, could you at least provide instructions for that? Users would need to know the exact list of needed files and packages (ideally with download links and signing keys), and a method to add those files to the .iso without making it non-bootable.

but the version of flashrom needed to update the mini v2/L14 aren’t packaged, at all. Currently, it has to be built from source.

(re)packaging ISOs is not something I’ve done or have any familiarity with. But at a minimum, you’d need the coreboot utility script, the files in the releases repo which correspond to the releases repo hash in the script, the packages for the dependencies listed in the script, and a cloned flashrom repo set to the commit hash listed in the script.

It doesn’t matter whether the packages are official or not. Of course, one can compile from source securely as well.

Would you be able to provide the links to all those files? I don’t mind to download them all and let the flash script find what it needs by itself. Maybe I can try using two USB sticks for a start.

Shooting form the hips: Could it be possible to refactor the script in a way so it does all the checking, all the downloading and all the installing in three separate and individually executable steps? The way I understand it all the functionality is already there?!

1 Like