Article published by: Leah Rowe in Canoe Leah Mode™
Date of publication: 26 October 2023
This new release, Canoeboot 20231026, released today 26 October 2023, is based on the Libreboot 20231021 release, porting changes in it on top of nonGeNUine Boot 20230717 as a base. The previous release was nonGeNUine Boot 20230717, released on 17 July 2023; the project named nonGeNUine Boot has been renamed to Canoeboot, in this release, which is the first ever release under the name Canoeboot.
Canoeboot provides boot firmware for supported x86/ARM machines, starting a bootloader that then loads your operating system. It replaces proprietary BIOS/UEFI firmware on x86 machines, and provides an improved configuration on ARM-based chromebooks supported (U-Boot bootloader, instead of Google’s depthcharge bootloader). On x86 machines, the GRUB and SeaBIOS coreboot payloads are officially supported, provided in varying configurations per machine. It provides an automated build system for the configuration and installation of coreboot ROM images, making coreboot easier to use for non-technical people. You can find the list of supported hardware in Canoeboot documentation.
Canoeboot’s main benefit is higher boot speed, better security and more customisation options compared to most proprietary firmware. As a libre software project, the code can be audited, and coreboot does regularly audit code. The other main benefit is freedom to study, adapt and share the code, a freedom denied by most boot firmware, but not Canoeboot! Booting Linux/BSD is also well supported.
Canoeboot is maintained in parallel with Libreboot, and by the same developer, Leah Rowe, who maintains both projects; Canoeboot implements the GNU Free System Distribution Guideline as policy, whereas Libreboot implements its own Binary Blob Reduction Policy.
No new mainboards have been added in Canoeboot 20231026, versus nonGeNUine Boot 20230717, but a slew of build system enhancements and new features have been ported from Libreboot.
However, the following mainboards added in Libreboot 20231021 have been excluded in this Canoeboot release, due to the GNU FSDG policy: HP EliteBook 2170p, HP EliteBook 8470p, Dell Precision T1650 and Dell Latitude E6430.
This new Canoeboot release imports the PHC argon2 implementation into GRUB, courtesy of Axel who initially ported the code to run under GRUB 2.06, but this Canoeboot release uses GRUB 2.12 (an RC revision from git, at present).
Axel’s code was published to this AUR repository which Nicholas Johnson then rebased on top of GRUB 2.12, and I then imported the work into Libreboot, with Johnson’s blessing; Canoeboot has inherited this work in full.
These libreboot patches added argon2 support, and have been ported to Canoeboot in this 20231026 release:
This means that you can now boot from encrypted
/boot partitions. I’m very grateful to everyone who made this possible!
Simply put, cbmk (the Canoeboot build system) is now easier to use than gbmk (the nonGeNUine Boot 20230717 build system) was; there are only 9 shell scripts in this release, versus 50 or so in the nonGeNU 20230717 release, and the command structure has been simplified.
The Libreboot 20231021 release has 12 scripts, bacause there are 3 more scripts there for handling the downloading of vendor code; since Canoeboot intentionally avoids doing that, those scripts are not needed in Canoeboot and have therefore been excluded. They are:
Libreboot’s build system, lbmk, is written entirely in shell scripts. It is an automatic build system that downloads, patches, configures and compiles source trees such as coreboot and various payloads, to build complete ROM images that are easier to install. More info about that is available in the lbmk maintenance manual - and you can read the cbmk maintenance manual for comparison.
The changes in those audits have been ported to this Canoeboot release.
Changes include things like vastly reduced code complexity (while not sacrificing functionality), greater speed (at compiling, and boot speeds are higher when you use the GRUB payload), many bug fixes and more.
In addition to coreboot firmware, the Canoeboot build system (lbmk) can now build serprog firmware, specifically
stm32-vserprog, on all devices that these projects support.
The serprog protocol is supported by flashrom, to provide SPI flashing. It can be used to set up an external SPI flasher, for flashing Canoeboot externally. This too has been ported from Libreboot.
Pre-compiled firmware images are available, for many of these devices, under the
roms/ directory in this Canoeboot 20231026 release! Riku Viitanen is the one who added this capability to Libreboot, which was then ported to Canoeboot.
Alper Nebi Yasak submitted patches that update the U-Boot revision in Libreboot, on
gru_kevin chromebooks. Additionally, the
cros coreboot tree has merged there with the
default tree instead (and the
default tree has been updated to coreboot from 12 October 2023).
Many improvements were made to these boards, which you can learn about by reading these diffs:
All of these patches have been ported to this Canoeboot release.
In Canoeboot 20231026 (this release):
d862695f5f432b5c78dada5f16c293a4c3f9fce6, 12 October 2023
coreboot/default (see above)
1c13f8d85c7306213cd525308ee8973e5663a3f8, 16 June 2021
e58b870ff926415e23fc386af41ff81b2f588763, 3 October 2023
1e1da7a963007d03a4e0e9a9e0ff17990bb1608d, 24 August 2023
4459ed60cb1e0562bc5b40405e2b4b9bbf766d57, 2 October 2023
In nonGeNUine Boot 20230717 (previous release):
e70bc423f9a2e1d13827f2703efe1f9c72549f20, 17 February 2023
8da4bfe5b573f395057fbfb5a9d99b376e25c2a4 2 June 2022
f7564844f82b57078d601befadc438b5bc1fa01b, 14 February 2023
ea1b7a0733906b8425d948ae94fba63c32b1d425, 20 January 2023
890233ca5569e5787d8407596a12b9fca80952bf, 9 January 2023
As you can see, all revisions are quite new in this release.
resources/scripts/ directory is now
script/, and what was
resources/ now only contains configuration data plus code patches for various projects, so it has been renamed to
config/ - I considered splitting patches into
patch/, but the current directory structure for patches is not a problem so I left it alone.
Also, the IFD/GbE files have been moved here, under
config/ifd/. These can always be ge-generated if the user wants to, using ich9gen, or using a combination of bincfg and ifdtool from coreboot, and nvmutil (to change the mac address) from Canoeboot or Libreboot.
These changes have been ported from the Libreboot 20231021 release, which are mostly the results of the two audits (mentioned above):
--mtime and option options in GNU Tar (if it is actually GNU Tar), when creating Tar archives. This results in partially reproducible source archives, and consistent hashes were seen in testing, but not between distros.
.git within lbmk, for the build system itself, if Git history was removed as in releases. This work around some build systems like coreboot that use Git extensively, and are error-prone without it.
grub.cfg, because it causes trouble in some non-interactive setups where the user sees an errant message on the screen and has to press enter. This fixes boot interruptions in some cases, allowing normal use of the machine. The pager was initially enabled many years ago, to make use of cat a bit easier in the GRUB shell, but the user can just enable the pager themselves if they really want to.
include/, and main scripts in
script/, called by the main
setvars function defined under
config/git are now concatenated, traversing recursively through the target directory; files first, then directories in order, and for each directory, follow the same pattern until all files are concatenated. This same logic is also used for patches. This now enables use of subdirectories, in some config/patch directories.
cp to copy links.
err, or just something that belongs on the error output (instead of standard output).
-B option in make commands.
/tmp, because it might be a tmpfs with little memory available; clone into
tmp/gitclone instead, within lbmk, and
mv it to avoid unnecessary additional writes (
mv is much more efficient than
cp, for this purpose).
target.cfg handling in vendor scripts, because they use the concatenated config format instead (they always have).
resources/scripts/ is now
resources/ was renamed to
config/; ifd and gbe files were also moved to
config/ifd/. Commands are now 1-argument instead of 2, for example the
./build boot roms command is now
read command that is built into
sh, reading each line. This is more efficient, and provides more robust handling on lines with spaces in them.
config/git have had certain
depend items removed, if a given project already defines it under
.gitmodules (within its repository).
target.cfg files in multi-tree projects coreboot, SeaBIOS and U-Boot. Unified to all such projects, under one script, and with improved error handling.
./build dependencies x commands still work as root (they’re the only commands available as root).
list command has been mostly unified, making it easier to tell (from lbmk) what commands are available, without having to manually poke around under
-T0 flag is now used, universally, on xz commands. This makes
xz run on multiple threads, greatly speeding up the creation of large tar archives.
-j in make commands, for multi-threading, but it relies on
nproc to get thread count, so this only works if you have
nproc (you probably don’t, if you run BSD; BSD porting is still on TODO for Canoeboot)
.gitcheck; now, a global git name/email config is always required. The only behaviour (setting local config, and unsetting) was quite error-prone under fault conditions, where cleanup may not have been provided, or when execution was interrupted, resulting sometimes in accidentally committing to
lbmk.git as author named
err is used to provide such behaviour. This results in all exits from lbmk being consolidated to
err, under fault conditions. - zero exits are also consolidated, going only through the main script, which has its own exit function called
lbmk_exit that provides
err function (and functions that use it) inside
include/err.sh; there is also
x_ which can be used to run a command and exit automatically with non-zero status, useful because it provides more verbose output than if you just relied on
set -e, and it still works when a script does not use
set -e - however, it is not used on all functions, because it works by executing
$@ directly, which can break depending on arguments. Therefore, some scripts just default to
|| err for providing breakage in scripts.
bin/, when it comes to flashing coreboot ROM images; it tells them to use
bin/ because those images do contain payloads, whereas the ones under
elf/ do not.
elf/, as are payloads, then they are joined separately by the usual ROMs build script, and these cached ROMs contain many changes in them that were previously handled by
moverom in the main ROM build script. Under the new design, repetitive steps are avoided; payloads are inserted into a copy of the cached ROMs under
TMPDIR, before being copied for keymaps and small files; this eliminates delays caused by slow compression (LZMA is always used, when inserting payloads). After crossgcc and the payloads are compiled, the ROM with coreboot builds in under a minute, whereas it would have previously taken several minutes on most Canoeboot-supported hardware.
include/ and its functions are called by the main build script, which provides a stub for this.
script/, inheriting the
TMPDIR variable set (and exported) by lbmk.
/tmp handling; a universal
TMPDIR is set (environmental variable) and exported to all child processes running lbmk scripts. On exit, the main tmp directory is purged, cleaning all tmp directories under it.
-e option in
sh was heavily relied upon to catch errors, but now errors are handled much more verbosely. Many fault conditions previously did not make lbmk exit at all, let alone with non-zero status, and zero status was sometimes being returned under some edge cases that were tested. Error handling is more robust now.
ich9gen) was removed, thus eliminating about 3000 source lines (of C code) from lbmk. The
nvmutil program, also provided by and originating from the Canoeboot project, can already change GbE MAC addresses. Coreboot’s bincfg can generate ich9m descriptors, and ifdtool can manipulate them; so the features provided by ich9utils were superfluous, since they are available in other projects that we ship. We now ship pre-built ifd/gbe configs on these machines, which can be modified or re-assembled manually if you want to. This eliminates a moving part from Canoeboot, and speeds up the build a little bit.
elf directory contains these, and the existing
bin directory still holds the full ROM images (containing payloads) when compiled.
build/boot/roms_helper script - the new style is much cleaner, mandating that logic be top-down, with a
main() function defined; it’s basically inspired by the OpenBSD coding style for C programs, adapted to shell scripts.
grub.elf is now used on all ROM images. The
grub.cfg goes in GRUB memdisk now, but can be overridden by inserting a
grub.cfg in CBFS; many behaviours are also controlled this way, for example to change keymaps and other behaviours. This results in much faster builds, because a different GRUB payload doesn’t have to be added to each new ROM image; such takes time, due to time-expensive LZMA compression. This, plus the optimised set of GRUB modules, also makes GRUB itself load much faster. All of the fat has been trimmed, though still quite a lot more than a Crumb.
/tmp at all, but now it’s pretty reliable.
All of the following are believed to boot, but if you have any issues, please contact the Canoeboot project. They are:
You can find this release on the downloads page. At the time of this announcement, some of the rsync mirrors may not have it yet, so please check another one if your favourite one doesn’t have it.
Besides deblobbing, there are two critical differences in how Canoeboot’s build system works in this release, versus the Libreboot 20231021 build system:
config/git/ because many of those entries were defined as submodules by each given project; in some serprog-related repositories, proprietary drivers get downloaded that are never actually compiled or executed in any way. Rather than deblob these in Canoeboot, the Canoeboot build system simply skips downloading those repositories altogether.
config/git/ for Canoeboot 20231026, that do not exist under Libreboot 20231021.
This quirk is only a minor difference. Severals scripts that handled dependencies for building non-FSDG-compliant boards (such as blob download scripts) have been excluded in this Canoeboot release, because they are not needed.
As a result, the Canoeboot build system is about 1250 sloc when counting shell scripts of the build system; the Libreboot build system is about 1750. This comparison is between Canoeboot 20231026 and Libreboot 20231021 - by contrast, Libreboot 20230625 was 3388 sloc, and GNU Boot 0.1 RC is 2111 sloc (counting shell scripts, because it uses the same design as lbmk and cbmk).
That ~1250 sloc in Canoeboot is with all the extra features such as serprog integration and U-Boot support (on actual mainboards, that you can flash it with). The build system in Canoeboot 20231026 is extremely efficient.
In addition to the Libreboot 20231021 changes, the following Libreboot patches were backported into this Canoeboot release, from Libreboot revisions pushed after the Libreboot 20231021 release came out:
These entries are from the Libreboot 20231021 change log, but these changes are not present in the Canoeboot 20231026 release:
/tmp for ROM images when inserting vendor files. In case
/tmp is a tmpfs and not much RAM is available, it is paramount that the user’s file system is used instead, where there is likely greater capacity; it is done under
tmp/ in lbmk (not to be confused with
util/ (not under
config/ifd so the vendorfile directory became redundant.
microcode_required="y" on most boards, but leave it set to
"n" on platfroms such as GM45 (ThinkPad X200/T400, Dell E6400, etc); anything FSDG compatible, in other words.
dl_path, don’t move it, when downloading and extracting a vendor file. This reduces the change of it being missing later when lbmk is run again.
The following boards are missing in Canoeboot 20231026, but are supported in the Libreboot 20231021 release; this is because they do not comply with FSDG policy:
Again, certain features cannot be merged from Libreboot and into Canoeboot, because of the restrictions set by Canoeboot policy (adhering to GNU FSDG). Here is an overview of the code present in Libreboot 20231021 that is missing in Canoeboot 20231026:
deblob-check script. (yes, it works on other code bases, besides Linux). This means that most mainboards no longer compile, in coreboot, and many u-boot targets no longer compile.
build/roms: These scripts build ROM images. For zero-blob boards, in other words boards that do not require binary blobs, regular Libreboot inserts CPU microcode by default, but copies each ROM to produce a corresponding, parallel zero-blobs version without CPU microcode. This censored version of Libreboot modifies the script in the following way: since the coreboot and uboot download scripts remove blobs anyway, including CPU microcode, the default compiled ROMs exclude microcode. Therefore, this version simply removes that logic, because it’s not needed.
blobutil: Anything pertaining to the downloading of vendor blobs has been removed. This includes
ME7 Update Parser and the like. It is not needed, in this version of Libreboot. Directories such as
resources/blobs/ (containing code and config data) has been removed. In regular Libreboot, there are certain required binary blobs that we cannot legally distribute on certain mainboards, so
blobutil auto-downloads them from the vendor while compiling ROM images, then it processes them (if needed) and inserts them; the scripts that produce release archives will delete these blobs, for the release, and those same scripts can be re-run on release ROMs, to re-insert binary blobs. It is completely automated, removing any need for manual intervention by the user, thus saving hours of time in some cases. Blobutil snaps them up like that and everything Just Works. It does this for many different types of blobs, including: Intel ME, Intel MRC, HP KBC1126 EC firmware, VGA ROMs - you just run 1 command on 1 ROM (or an entire collection of ROMs) and it does it, automatically detecting what is needed for the given ROM image, per mainboard definition. Very easy to use. This highly innovative technology does not exist in Censored Libreboot.
blobutil, during the build process or post-release in the Libreboot build system. This includes: Intel ME firmware, Intel MRC firmware, HP KBC1126 EC firmware and VGA option ROM for Nvidia GPU variant of Dell Latitude E6400.
lbmk: Code that executes blob-related scripts has been removed.
update/release: correspondingly deleted files are no longer copied by these scripts (they are the scripts that generate tar archives for Libreboot releases, after everything is compiled). The build logic no longer bothers to scrub non-redistributable inserted binary blobs from certain ROM images, because 1) those corresponding mainboards are no longer supported anyway and 2) the logic for downloading/inserting those blobs no longer exists. So there’s nothing to do.
It’s not actually a lot of code that was removed. The actual diff that did this is very large, because it also removed the coreboot configs for the removed boards, and those configs are very large.
Libreboot is superior to Canoeboot, in every way. You should use Libreboot. Use of Canoeboot is even dangerous, because lack of microcode updates in Canoeboot could potentially lead to data loss due to memory corruption.
Read more about the Binary Blob Reduction Policy of the Libreboot project. The Canoeboot project is provided as a proof of concept, to demonstrate just how awful Libreboot used to be, before it implement the new policy in November 2022.
Canoeboot is a worthless project, but engineered to a high standard. It’s necessary to do this, because there are some people who won’t adequately see the problem unless it actually exists; Canoeboot is not a problem, because it’s not the only choice, but there was a time when osboot didn’t even exist, let alone the new Libreboot, and the other more pragmatic coreboot distros do not support as much hardware as Libreboot does today.
You should use Libreboot, even if your hardware is compatible with Canoeboot. I make these Canoeboot releases, specifically so that I have something to crap all over. I could criticise GNU Boot more heavily, but GNU Boot is even more inferior; I make Canoeboot as good as it can feasibly be at any point in time, and criticise that result. My arguments are stronger when an example exists, especially a strong example such as Canoeboot. If the best possible solution is still inferior, then that will further invalidate the even lesser solutions, and that is the entire purpose of Canoeboot; I do Canoeboot releases, specifically so that I can crap all over them. I’m allowed to do that if it’s mine.
I say again. Canoeboot is inferior.
On this day, the websites of Censored Libreboot and nonGeNUine Boot are being redirected (HTTP 301 return) to the Canoeboot website.
An archive of nonGeNU 20230717’s announcement is contained on this website, but not Censored Libreboot 20230717; it was virtually identical to nonGeNUine Boot 20230717, the latter of which was just a re-brand of Censored Libreboot.
If you do want to see either nonGeNU or C-Libreboot, go to these links:
And for nonGeNUine Boot, though the code (website and code) is included in the Canoeboot repositories, here are the original repositories:
You can find the actual software release archives for nonGeNUine Boot 20230717 and Censored Libreboot 20230710 under Libreboot rsync mirrors, in the
canoeboot directory. They have been moved there, from where they were previously hosted.
The following binary blobs were overlooked, and are still present in the release archive for Canoeboot 20231101 and 20231026; this mistake was corrected, in the Canoeboot 20231103 release, so you should use that if you don’t want these files. They are, thus:
Thanks go to Craig Topham, who is the Copyright and Licensing Associate at the Free Software Foundation; you can find his entry on the FSF staff page. Craig is the one who reported these.
The Canoeboot 20231026 and 20231101 release tarballs will not be altered, but errata has now been added to the announcement pages for those releases, to let people know of the above issue.
You are advised, therefore, to use the Canoeboot 20231103 release.
This file was also overlooked, and is still present in the release tarball:
This has now been removed, in the Canoeboot git repository (
cbmk.git), and this file will absent, in the next release after Canoeboot 20231107. Thanks go to Denis Carikli who reported this. The patch to fix it is here:
Markdown file for this page: https://canoeboot.org/news/canoeboot20231026.md
This HTML page was generated by the Untitled Static Site Generator.