Is there any documentation explaining how I can update Coreboot on my Librem laptop in offline mode, i.e., without Internet access?
The background is that I am using Qubes OS and it’s strong isolation between network VM, update VMs, and other VMs gives me a great peace of mind. I do not want to abandon my security practices after that.
According to the official documentation, I would have to boot PureOS from a USB stick, connect to the Internet, and run the corresponding script, which will do everything for me. It sounds very insecure to me (spoiled by Qubes of course), because an operating system without latest security updates will have unrestricted Internet access and will reflash my BIOS!
Instead, I would like to prepare a bootable USB stick containing everything I need for the update. How can I do this?
I understood that it also requires the access to the Internet.
Unfortunately running Qubes does not make me a programmer. I might figure out after some struggling how to extract the actions from that script, but I would not prefer to play with fire here risking to brick my machine… I wish Purism had a simple bootable iso for reflashing the latest Coreboot and Pureboot.
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…
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?
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).
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).
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’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.
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.
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.
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.