Canoeboot 25.06 "Onerous Olive" released! FSDG-compliant BIOS/UEFI firmware. Sandy/Ivybridge/Haswell support added.
- Vous devez vous identifier ou créer un compte pour écrire des commentaires
Hello everyone!
I'm Leah Rowe, the founder and lead developer of Canoeboot which is free/libre BIOS/UEFI firmware, implemented as a 100% Free coreboot distro based forked from Libreboot. It is maintained in parallel with Libreboot, doing releases in sync with its releases (parallel release schedule).
Canoeboot is provided for the hardcore FSF/GNU-type free software activists, who want to ensure that they *only* use Free Software. It also provides many security benefits over conventional boot firmware.
Today I made a new Canoeboot release, namely Canoeboot 25.06, codename "Onerous Olive":
https://canoeboot.org/news/canoeboot2506.html
Lots of bug fixes have been applied, mostly to the build system, but there are also some fixes made to the GRUB payload, including security fixes. Since this is a stable release, the focus has been on fixing issues and not on new boards/features - though a lot of boards were also added, and even more will be in the next release for later in the year.
I already posted about the new boards here:
https://trisquel.info/en/forum/fsdg-compliant-sandyivybridgehaswell-support-added-canoeboot
A lot of newer ThinkPads, Dell Latitudes and OptiPlex machines were added, of the newer Intel Sandybridge, Ivybridge and Haswell platforms. This includes newer ThinkPads such as X230/T440p, and all the newer Dell Latitude models. The Latitutes are really nice because they can be flashed without disassembly.
These boards are provided blob-free ini Canoeboot, and the way this is done is described in the release, and that previous trisquel forums thread, and the new article about it here:
https://canoeboot.org/docs/install/ivy_has_common.html
The following boards have been added since the Canoeboot 25.04 release:
Dell OptiPlex 7010 SFF desktop
Dell OptiPlex 9020 SFF desktop
Dell OptiPlex 9020 MT desktop
Dell Latitude E5420 laptop
Dell Latitude E5520 laptop
Dell Latitude E5530 laptop
Dell Latitude E6220 laptop
Dell Latitude E6230 laptop
Dell Latitude E6320 laptop
Dell Latitude E6330 laptop
Dell Latitude E6420 laptop
Dell Latitude E6430 laptop
Dell Latitude E6520 laptop
Dell Latitude E6530 laptop
HP Elite 8200 SFF desktop
HP Elite 8300 CMT desktop
HP Elite 8300 USDT desktop
Dell Precision T1650 desktop
Lenovo ThinkPad T420 laptop
Lenovo ThinkPad T420s laptop
Lenovo ThinkPad T430 laptop
Lenovo ThinkPad T440p laptop
Lenovo ThinkPad T520 laptop
Lenovo ThinkPad T530 laptop
Lenovo ThinkPad W530 laptop
Lenovo ThinkPad W541 laptop
Lenovo ThinkPad X220 laptop
Lenovo ThinkPad X230 laptop
Lenovo ThinkPad X230T laptop
Enjoy!
Does Canoeboot work with Virtual Machines ? Also amazing work.
Thanks
In fact, it does! Canoeboot supports QEMU. Download(or compile) the QEMU image for Canoeboot. Target name: qemu_x86_64_12mb
Info about how to use it is here:
https://canoeboot.org/docs/misc/emulation.html
This replaces QEMU's own virtual BIOS. It can be useful for testing new payloads; for example, my modifications to the x86_64 U-Boot payload were largely tested in QEMU, complemented by real hardware testing.
Great!
Thank you, Leah!
Mixing machines that are practically free (like the ThinkPad X200, whose only proprietary component is the EC) with machines that have a castrated ME doesn’t seem like a good idea. When Libreboot was truly free, it avoided this, and GNU Boot upholds that same policy from early Libreboot.
Combining hardware that respects software freedom almost entirely (like the ThinkPad X200) with hardware that has a castrated ME isn’t ideal because it dilutes what is free with what is only partially free. It’s possible, though, that this blurring is the intended goal of this project.
Moreover, I suspect that this blurring is the result of a malicious attempt to undermine user freedom, because machines with a castrated ME, which were truly non-free, were completely separated in your osboot project rather than being in your old Libreboot (when it was free). So, in reality, you are fully aware of the problem and know exactly what you’re doing.
More specifically: Canoeboot (and old Libreboot) previously adhered to both RYF and FSDG. New Canoeboot, since this release, adheres only to FSDG.
FSDG pertains to the software project itself, specifying that it must not distribute non-free software, nor recommend any such software. Canoeboot adheres to this policy.
RYF is the same policy, but applies to an entire commercial product. Since Canoeboot is merely a software project, this makes no sense.
The new machines are supported, without distributing proprietary software. No proprietary software is recommend either; you don't modify or update any of what's already there. You merely flash the BIOS region, containing coreboot, and that part is all free software (even microcode is excluded).
I realise that this could cause some people to raise their eyebrows, but this is fully in adherence to GNU FSDG.
I was going to do this already in Libreboot in 2017, but held off back then. I already spoke to several people at the FSF, and I also spoke to the GNUBoot people about this. They're all pretty much on board with it. It is technically compliant with GNU policy.
It's just like when you install a free FSDG GNU/Linux distro like Trisquel, on a system with a non-free BIOS. Does that make Trisquel non-free? Should Trisquel exclude support for anything other than hardware with free boot firmware? No. That would be madness.
>"machines that are practically free (like the ThinkPad X200, whose only proprietary component is the EC)"
We have a term for systems that are "practically free" with only minor non-free components. We call them "non-free". Once they are in the non-free category, there are no "better degrees of non-free" and "worse degrees of non-free". There's just non-free. The X200 is non-free.
Canoeboot is 100% free software. Compile it yourself if you want, and look at cbmk.git to see what it's doing. It's not handling blobs in any way whatsoever. Except deleting them from coreboot (deblobbing).
On the newer machines, it just so happens that there is an Intel ME, but you're not handling that in Canoeboot. The flash is divided into partitions:
* IFD
* GBE
* ME
* BIOS
You flash IFD, GBE and BIOS, but not ME. The custom IFD provided by Canoeboot also sets the altMeDisable bit, which disables the ME after early bringup.
This differs from Libreboot, because Libreboot's build system downloads Intel ME at build time and inserts it, so that you also flash that region too. Canoeboot can't handle blobs, because of its policy (GNU FSDG), hence this design difference. This also makes Canoeboot more hazardous, because you have to remember not to overwrite Intel ME.
I understand someone's concern with this in, say, an RYF context, but this arrangement is fully FSDG compliant, since Canoeboot isn't handling the ME at all. You're just leaving what's already there in place.
I suspected that there might be a few people who would misunderstand this. It's documented on Canoeboot, and I've said so repeatedly, but some people just don't want to read.
I defy anyone to tell me otherwise.
Everything has nuances. Even freedom.
what does not have nuance is the fact that Canoeboot's list of supported mainboards recently doubled in size. I expect to double it again by the end of the year.
yes, i have quite unambiguous plans to modernise canoeboot entirely. stay tuned for Canoeboot 25.12 "Thrifty Tomato" (December 2025 release)
Can you clarify what this is about? About the newer canoeboot computers some non free bios software stays on the computer after you have installed canoeboot? If so does these pieces of non free software do anything or are they disabled?
Thank you.
Yes, Intel ME is still present, on the newer machines. As already explained on the website, a special config is used that stops it from running after early boot time.
So the ME is in effect disabled. This is done with two separate configurations:
* Set the HAP/altMeDisable bit in the Intel Flash Descriptor, which is config data stored in flash
* Use "ME Soft Temporary Disable" in coreboot, which does the same thing
Specifically, the ME is separated into many modules. The first ones that run are ROMP and BUP, which are analogous to the ME's own boot firmware; only these run, and the ME stops running after that, so it's sort of like running coreboot without a payload.
Canoeboot can't distribute the ME, because that would violate GNU FSDG. So, it doesn't shrink the ME region, because that would require handling (and therefore distributing/recommending the handling of) proprietary software.
So Canoeboot is fully free software and is flashed *around* the ME region in flash, so that you only handle free software. In this way, it technically complies with GNU FSDG.
It's a bit technical for the layman to understand, but that's the gist of it.