If you want to understand the beef Canoeboot has with GNU Boot, please read the about page, the Libreboot Binary Blob Reduction Policy and the GNU Boot article on libreboot.org - all of that energy has fuelled the creation of this page, and in fact the entire Canoeboot project. The main purpose of Canoeboot is to be technically superior to GNU Boot, while complying with all of its policies by providing ROM images and source tarballs adhering to the GNU Free System Distribution Guidelines, even though GNU FSDG is deeply flawed; this page describes precisely how that has been achieved, and it will be updated over time as Canoeboot continues to develop.
tl;dr as of 26 October 2023, Canoeboot code is about 1 year ahead of GNU Boot in terms of development, and about 2 years ahead in terms of documentation. Read on, if you want details. GNU Boot is also known as gnuboot.
Canoeboot and GNU Boot are both forks of Libreboot, designed to comply with the GNU Free System Distribution Guidelines. This page is maintained, to show the differences between these two projects.
This current version of the page pertains to Canoeboot 20231026 versus GNU Boot 0.1 RC. You can find GNU Boot (“gnuboot”) on the GNU Savannah website.
You can also read the Canoeboot 20231101 changelog; that release only came out 7 days after the 20231026 release, so the rest of this page is more or less accurate, when combined with the facts on the 20231101 announcement.
This fact is very important; nonGeNUine Boot’s 20230717 changelog is relative to Libreboot 20220710, and Canoeboot 20231026’s changelog is relative to nonGeNUine Boot 20230717’s changelog.
Therefore, this page will analyse differences in both projects, at these two points. First, let’s analyse GNU Boot, with the tag reset to
0.1-rc1, which corresponds to commit ID
a64d284fd798d843133c9d7274bba17bd7837174. Since GNU Boot also contains the Libreboot history that it forked from, it contains the Libreboot 20220710 release tag, so we can do this:
git log --graph --pretty=format:'%Cred%h%Creset %s %Creset' --abbrev-commit 20220710..0.1-rc1
Within the GNU Boot git repository, this would yield the following response:
* a64d284 .gitignore: order alphabetically * 0df4fe5 GRUB: config from HDD/SSD: Add support for gnuboot_grub.cfg * ce13d22 GRUB: Use GNU Boot logo * 74b678c GRUB: Say the name GNUBoot in the grub menu * eeddd2b build/dependencies: debian: adding python-is-python3 to build seabios properly * 58b8e09 coreboot/fam15h: don't build ada toolchain for generic platforms * f7c0fec coreboot/fam15h: update code base, deblob, unset CONFIG_STM (see bug #64535) * de9297f coreboot/fam15h: fix crossgcc acpica build on newer hostcc * c38348d coreboot/fam15h: fix for gcc/gnat building * 0d77d99 coreboot/fam15h: fixing binutils not building properly * b773079 coreboot/default, coreboot/fam15h: use GNU mirror for acpica * bf17993 Continue Libreboot under the GNU project
And that’s all. The fam15h-related fixed are actually merged from the
fsdg20230625 branch of Libreboot, made during July 2023. See: https://browse.libreboot.org/lbmk.git/log/?h=fsdg20230625
The other patches are also merged (cherry-picked) from Libreboot! The above commit log is all that GNU Boot did, for their 0.1 RC1 release.
Therefore, to know the differences between Canoeboot and GNU Boot, I will copy all items first from the nonGeNUine Boot 20230717 change log, and then the Canoeboot 20231026 change log, but I will skip those entries that define features which GNU Boot already has.
On this day, GNU Boot’s current commit ID (in the
main branch) is
54c6ae497d49c233b654c171978baa77b90ffe17 from 12 October 2023. Most of the changes since 0.1 RC1 up to that commit are just documentation changes, and even still, only cherry-picking minor patches here and there that were already done in Libreboot, in some cases years ago. It’s worth noting that the GNU Boot documentation is based on Libreboot documentation from late 2021 or at most, very early 2022.
I don’t need to compare documentation, and it would take too long. Their documentation is 2 years out of date, what more is there to say?
Now, feature comparisons in the build systems:
Canoeboot has these boards fully supported, that GNU Boot currently lacks support for:
d862695f5f432b5c78dada5f16c293a4c3f9fce6, 12 October 2023
1c13f8d85c7306213cd525308ee8973e5663a3f8, 16 June 2021
e58b870ff926415e23fc386af41ff81b2f588763, 3 October 2023
1e1da7a963007d03a4e0e9a9e0ff17990bb1608d, 24 August 2023
4459ed60cb1e0562bc5b40405e2b4b9bbf766d57, 2 October 2023
b2e8bd83647f664260120fdfc7d07cba694dd89e, 17 November 2021
1c13f8d85c7306213cd525308ee8973e5663a3f8, 16 June 2021
f7564844f82b57078d601befadc438b5bc1fa01b, 25 October 2021
1281e340ad1d90c0cc8e8d902bb34f1871eb48cf, 24 September 2021
As you can see, Canoeboot’s revisions are a lot newer.
Canoeboot 20231026 contains a heavily patched version of GRUB, which contains argon2 support. This allows full decryption of LUKS2 volumes, without having to switch to different key derivation (PBKDF2) and without needing to use LUKS1. You can simply use the default LUKS2 setup provided by any distro, and it will work. More information is available about GRUB cryptomount, in the GNU+Linux guide - search on that page for LUKS2 or argon2.
GNU Boot completely lacks this feature, as of 26 October 2023. It can only support LUKS2 if the key derivation is downgraded to PBKDF2 (insecure, or to LUKS1 (also insecure).
For all intentions, the average user cannot have a fully encrypted system on GNU Boot. They must leave
/boot unencrypted on GNU+Linux distros.
With Canoeboot, you can have encrypted
/boot very easily. This is a boon for security, because it reduces the chance of someone tampering with your data successfully, and combined with other steps, can be used to reduce the risk of evil maid attacks (by making it infeasible).
Canoeboot can build firmware images for RP2040 and STM32 microcontrollers, using
stm32-vserprog respectively. This can be used to set up an SPI flasher of high quality, but these parts are low-cost.
GNU Boot does not support this feature, as of 26 October 2023.
There are 9 shell scripts in Canoeboot 20231026, versus about 50 in GNU Boot 0.1 RC1, because GNU Boot uses the pre-audit design; Libreboot used to have lots of very simple scripts, but ended up with a lot of code repetition.
The new lbmk design generalises all of the logic, doing away with the very hacky logic that existed in the old build system design.
The interface in Canoeboot’s build system is much easier to use. For example, the commands are shorter, and easier to remember. See: cbmk maintenance manual tells you everything about the Canoeboot build system.
GNU Boot doesn’t even have a maintenance manual, in their version. Their documentation exists in the same repository as code, but their version of
docs/maintain/ does not actually contain any instructions, at least as of commit ID a64d284fd798d843133c9d7274bba17bd7837174 on 17 August 2023.
Canoeboot has much better documentation, but this is obvious if you’ve been paying attention. As already stated: GNU Boot’s documentation is horribly out of date, even relative to the version of Libreboot that they’re using! (which itself is also horribly out of date)
Smaller doesn’t mean worse; in fact, Canoeboot’s build system is more efficient. It’s about 1250 sloc (source lines of code), when counting shell scripts in the core of the build system. Libreboot, Canoeboot and GNU Boot build systems all use the same design, written in shell scripts.
1250 sloc in Canoeboot, versus 2111 in gnuboot; gnuboot however lacks many of the features and improvements that you’re about to see below. The Canoeboot build system does several times as many things, in half the amount of code! The code is generally just more reliable, less error prone, and easier to work with, in Canoeboot. GNU Boot uses a very old version of the Libreboot build system design, from long before I started any massive audits. There have been three Libreboot build system audits in 2023, as of 26 October 2023.
Three audits, and Canoeboot has inherited the improvements of all of them. GNU Boot’s design is based on the pre-audit lbmk codebase.
Build system / performance improvements in Canoeboot:
--mtimeand 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.
.gitwithin 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
setvarsfunction defined under
config/gitare 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.
cpto copy links.
err, or just something that belongs on the error output (instead of standard output).
-Boption in make commands.
/tmp, because it might be a tmpfs with little memory available; clone into
tmp/gitcloneinstead, within lbmk, and
mvit to avoid unnecessary additional writes (
mvis much more efficient than
cp, for this purpose).
target.cfghandling in vendor scripts, because they use the concatenated config format instead (they always have).
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 romscommand is now
readcommand that is built into
sh, reading each line. This is more efficient, and provides more robust handling on lines with spaces in them.
config/githave had certain
dependitems removed, if a given project already defines it under
.gitmodules(within its repository).
target.cfgfiles in multi-tree projects coreboot, SeaBIOS and U-Boot. Unified to all such projects, under one script, and with improved error handling.
./build dependencies xcommands still work as root (they’re the only commands available as root).
listcommand has been mostly unified, making it easier to tell (from lbmk) what commands are available, without having to manually poke around under
-T0flag is now used, universally, on xz commands. This makes
xzrun on multiple threads, greatly speeding up the creation of large tar archives.
-jin make commands, for multi-threading, but it relies on
nprocto 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.gitas author named
erris 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
errfunction (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
|| errfor 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/, 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
moveromin 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
TMPDIRvariable set (and exported) by lbmk.
/tmphandling; a universal
TMPDIRis 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.
shwas 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
nvmutilprogram, 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.
elfdirectory contains these, and the existing
bindirectory still holds the full ROM images (containing payloads) when compiled.
build/boot/roms_helperscript - 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.elfis now used on all ROM images. The
grub.cfggoes in GRUB memdisk now, but can be overridden by inserting a
grub.cfgin 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.
/tmpat all, but now it’s pretty reliable.
cros: Disable coreboot-related BL31 features. This fixes poweroff on gru chromebooks. Patch courtesy of Alper Nebi Yasak.
u-boot: Increase EFI variable buffer size. This fixes an error where Debian’s signed shim allocates too many EFI variables to fit in the space provided, breaking the boot process in Debian. Patch courtesy Alper Nebi Yasak
util/spkmodem-recv: New utility, forked from GNU’s implementation, then re-written to use OpenBSD style(9) programming style instead of the originally used GNU programming style, and it is uses OpenBSD
pledge()when compiled on OpenBSD. Generally much cleaner coding style, with better error handling than the original GNU version (it is forked from coreboot, who forked it from GNU GRUB, with few changes made). This is a receiving client for spkmodem, which is a method coreboot provides to get a serial console via pulses on the PC speaker.
extra.shdirectly from given coreboot tree. Unused by any boards, but could allow expanding upon patching capabilities in lbmk for specific mainboards, e.g. apply coreboot gerrit patches in a specific order that is not easy to otherwise guarantee in more generalised logic of the nonGeNUine Boot build system.
util/e6400-flash-unlock: New utility, that disables flashing protections on Dell’s own BIOS firmware, for Dell Latitude E6400. This enables nonGeNUine Boot installation without disassembling the machine (external flashing equipment is not required). Courtesy Nicholas Chin.
cbutils: New concept, which implements: build coreboot utilities like cbfstool and include the binaries in a directory inside lbmk, to be re-used. Previously, they would be compiled in-place within the coreboot build system, often re-compiled needlessly, and the checks for whether a given util are needed were very ad-hoc: now these checks are much more robust. Very centralised approach, per coreboot tree, rather than selectively compiling specific coreboot utilities, and makes the build system logic in nonGeNUine Boot much cleaner.
gru_kevinchromebooks, U-Boot is used instead of Google’s own depthcharge bootloader. It has been heavily modified to avoid certain initialisation that is replaced by coreboot, in such a way that U-Boot is mainly used as a bootloader providing UEFI for compliant GNU+Linux distros and BSDs. Courtesy Alper Nebi Yasak.
sh(though, many dependencies still use GNU extensions, such as GNU Make, so this portability is not directly useful yet, but a stepping stone. nonGeNUine Boot eventually wants to be buildable on non-GNU, non-GNU/Linux systems, e.g. BSD systems)
nvmutil- can randomise the MAC address on Intel GbE NICs, for systems that use an Intel Flash Descriptor
grub.cfgfiles on the HDD/SSD.
So, in conclusion: this page is not trying to tell you why you should use Canoeboot; rather, it’s just telling you that someone worse exists. Canoeboot and GNU Boot are both inherently flawed in their designs; both projects are completely inferior to the Libreboot project, for all the reasons laid out in the Binary Blob Reduction Policy - the Canoeboot project is provided, specifically, to prove the merits of that policy, by showing what Libreboot would have been by now if it continued adhering to GNU policy, instead of changing to its current Blob Reduction Policy.
Libreboot provides all of the same blob-free configurations as Canoeboot, when possible on any given mainboard, and that is the preference, but the FSF/GNU dogma states that the user must never run any proprietary software. This dogma is wrong; a more correct approach is to say that proprietary software is bad, because it restricts the user’s freedom to study and modify the software; it removes their power to say no when the developer wants to change the program in a bad way, it leaves them at the mercy of that developer - the point is this:
Free software is good, and we should be promoting as much of it as possible. This means that a hardline no-blob approach like the policy implemented by Canoeboot (or GNU Boot for that matter), is entirely misguided, because it will only alienate those who just want some free software. Most people like the idea of software freedom but cannot go all the way yet; we should encourage people to make the right choices, but otherwise just help them in whatever way we can, meeting people where they’re at right now.
And that is why Libreboot exists in the way that it does. Canoeboot serves as an example of what would happen in the best-case scenario if Libreboot never changed its policy. The best possible release of Canoeboot will still be missing a ton of boards and features from Libreboot. Indeed, the Canoeboot 20231026 and nonGeNUine Boot 20230717 both illustrate that quite nicely.
Markdown file for this page: https://canoeboot.org/gnuboot.md
This HTML page was generated by the untitled static site generator.