FSDG-compliant Sandy/Ivybridge/Haswell support added to Canoeboot
I'll have Canoeboot 25.06 RC1 out soon. ETA Saturday, 24 May 2025. This will be the first RC, in a series of RCs until the final, official 25.06 release at the end of June.
I pushed this patch today, which will be included in Canoeboot 25.06 RC1 and beyond:
https://codeberg.org/canoeboot/cbmk/commit/6577abc60aadc0f40a4b5dd2ad06f827b1dbd132
It adds support for many newer Intel-based platforms to Canoeboot, in a matter that fully complies with GNU Free System Distribution Guidelines. This includes even Haswell platform, which I've tested extensively.
The Intel SandyBridge and Ivybridge platforms in particular have been tested by me, on and off, for several years now and I've concluded that they are basically fully stable, even without microcode updates. The same applies to Haswell, which as of last year has fully free initialisation in coreboot (even raminit is libre).
It's something I planned to do in Libreboot 10 years ago, but held off at that time; I had other concerns. I finally got round to it.
It will probably be considered controversial, within the FSF community, because it complies with FSDG but the machines, in the setups provided, would not quality for RYF, and Canoeboot (and it's base, Libreboot, prior to the policy change in November 2022) also adhered strongly to RYF.
Yet RYF applies to an entire commercial product, e.g. pre-installed ThinkPad, whereas FSDG only applies to a software project, e.g. Canoeboot. Both policies say the same thing: do not distribute proprietary software, and do not promote its use. They merely differ in scope, where FSDG is narrower in that it only applies to a software project e.g. Canoeboot.
On Intel Sandybridge, IvyBridge and Haswell platforms,
the flash is divided into these partitions:
* Intel Flash Descriptor (IFD)
* Intel Management Engine (ME)
* Intel Gigabit Ethernet NVM (GbE)
* Platform Data
* BIOS
IFD contains many configuration details of the entire
machine, but for our purpose, you might compare this
to the MBR or GPT section (partition table) on an HDD
or SSD. It does, among other things, define these regions.
Intel Management Engine is a coprocessor that handles,
among other things, certain power management and OOB
execution for things like Intel AMT, providing remote
management features; it also implements a soft TPM on
some platforms, and (on later platforms) Intel Boot Guard.
GbE contains configuration data for the onboard ethernet
chipset, if it's an Intel chipset. It also stores the
MAC address.
Platform Data is essentially just text, where you can
store any number of things. Vendors will sometimes put
information here e.g. version information for firmware.
The BIOS region contains actual boot firmware, for
example Canoeboot.
The Intel ME is a binary blob, so it cannot be included
in Canoeboot. On *Libreboot*, we handle this where needed,
by automatically downloading it from a vendor, and
processing it with the me_cleaner utility which disables
the ME after early bringup; only the ROMP and BUP modules
remain. These are essentially an analog of coreboot, as
they initialise the Intel ME. The Intel ME's own bootrom
executes the ME firmware stored in system flash, from
the ME region.
The *Canoeboot* setup differs greatly from Libreboot, in
that the Intel ME is not handled at all, on these platforms.
It is possible to still disable early ME bringup, by setting
the HAP (ME AltDisable) bit in the IFD; coreboot also has
an option called ME Soft Temporary Disable, and we use this
by default.
With use of either HAP and/or Temporary Disable, a full ME
region, with nothing removed (no me_cleaner) is functionally
identical, as this means only the ROMP and BUP modules will
run, and other modules are disabled.
Libreboot handles Intel ME by generating a *full* image,
including Intel ME, downloading the ME firmware at build
time; Libreboot's way of doing it violates GNU FSDG, and
thus could not be used in Canoeboot.
Canoeboot *does not* handle the Intel ME, but it doesn't
need to. We simply provide images where the Intel ME region
in the ROM is all zeroes. If you then flash the ME region
with that, it will result in a brick; however, you can avoid
flashing the ME region.
The flashprog software (also flashrom which we no longer
use) can be made to flash only specific parts of the flash,
by using either the --ifd option, or by using a layout file.
To generate a layout file, do this on a Canoeboot ROM:
./ifdtool -f layout.txt canoeboot.rom
You can then do e.g.:
./flashprog -l layout.txt -i fd canoeboot.rom
./flashprog -l layout.txt -i gbe canoeboot.rom
./flashprog -l layout.txt -i bios canoeboot.rom
In these examples, fd means IFD, gbe means GbE and
bios means BIOS, so you flash these regions. If you
wanted to flash Intel ME, you could use -i me, but
Canoeboot users migrating from factory firmware or
Libreboot can simply leave the ME region alone.
For all of these machines being added, the BIOS region
is entirely free software; even microcode updates are
excluded. The machines run just fine without microcode
updates, after extensive testing.
The IFD and GBE are not software; they are just config,
and their data format is fully documented by public
Intel datasheets. Canoeboot provides the nvmutil software
for changing GBE MAC addresses, and also ifdtool from
coreboot which can be used to modify IFD if you wish.
The general rule of thumb is this:
* If flashing Canoeboot from factory firmware, please
flash both the IFD and BIOS regions; you may also
modify the GBE region if you wish
* If flashing Canoeboot from Libreboot firmware, please
note that Libreboot *shrinks* the ME, and uses a different
IFD layout; some Dell mainboards also use 16KB GbE in
the Canoeboot setup, mirroring what the vendor did, where
Libreboot corrected this to 8KB:
* Therefore, if flashing Canoeboot from Libreboot, please
flash ONLY the GbE and BIOS regions; do not flash the IFD
region.
Libreboot's way of doing it is superior, because you don't
need to care what's in the original flash, since Intel ME
and other vendor files are automatically downloaded at
build time and inserted into images, or inserted after
the fact by use of a special script on release images.
Canoeboot's method has risks, because for example you might
ignore this entire commit message or the documentation that
I'm going to write covering these facts, and you would then
possibly overwrite the ME region with zeroes, or something
else stupid. If you did do that, you could always just build
Libreboot or something, and use that, but obviously We in
the Canoeboot project do not recommend this, as it would
be extremely unGNU.
At this time, as I write this, only the cbmk commit exists; I'm spending all of today importing and adapting Libreboot documentation, for these newer machines. Adapting it for inclusion on canoeboot.org.
The Canoeboot version, of this documentation, will teach you how to flash the 100% free software configuration provided by Canoeboot, into the BIOS region of the flash.
The Canoeboot method is basically this: if a machine requires binary blobs, Canoeboot will figure out a way to flash those machines while not providing any blobs itself.
So for example, the Intel ME that your system came with would remain unmodified. You would flash Canoeboot into the BIOS region, and set the ME AltDisable (HAP) bit in your Flash Descriptor.
I have another series of laptops that I will be doing for CAnoeboot, that aren't available in CAnoeboot yet: HP EliteBooks, of ivy/sandybridge generation. These use EC firmware in the flash, but my recent testing indicates that it is of the same size in the original vendor firmware, and not compressed or encrypted in any way. Therefore, Canoeboot could provide a fully free image for these machines, with the EC part being all-zeroes - then you would flash around the existing EC firmware, being careful not to overwrite it. More testing is needed on the EliteBooks, so these will probably be in 25.06 RC2, not RC1.
Libreboot handles those elitebooks by simply downloading and inserting the EC firmware from vendor updates. This can't be done in Canoeboot, due to GNU FSDG.
However, my priority as always is increasing user freedoms, by removing as much proprietary software as possible.
So this change in Canoeboot does exactly that, providing as much freedoms as possible to users on these newer machines; however, *Canoeboot will NOT* distribute blobs!
The Canoeboot implementation on these newer machines is vastly different from Libreboot's implementation, on those same machines, in that Canoeboot does not provide binary blobs at all, and since it is also an FSDG coreboot distro, it can't tell you to download or install them in any way. That means Canoeboot has to tell you how to piggyback off of what's already in flash.
Kind of like how like, you know, most non-coreboot systems out there, you know, the fully proprietary UEFI firmware that are common, can still boot GNU/Linux. On those machines you can install an FSDG GNU/Linux distro, an otherwise proprietary system. This new development in Canoeboot follows the same theme, but in the context of your boot firmware.
Like I said, this is probably going to be controversial. I've meticulously designed this so that it complies fully with GNU Free System Distribution Guidelines, both in spirit and in practise.
I'll have docs published later today.
This is a huge step forward Leah! Awesome work!
I am a translator!
If I got it right, this leaves the Intel ME on the flash and let it run, but with the HAP bit.
By leaving the existing ME and not installing an ME that went through me_cleaner, this may respect the FSDG, but the computer still needs the blob (ME) to boot. I see descriptions in this discussions that literrally say that some computers will be running blobless with canoeboot (ivy bridge, sandy bridge, haswell) while this is not the case.
I do hope that, once this is added to canoeboot, the website will tell the truth clearly: the intel ME is still there, it is just that some remote access function is supposed to be disabled, but as this is not free software, no one can say what the supposedly disabled ME exactly does.
That's my question down below - Leah said HAP bit disabled is functionally the same as me_cleaner cleaned. I would like more information about the functional comparison - is there no difference, or is there some observable difference? I do not know.
there is no difference at all. none whatsoever. the AltDisable/HAP bit is put there by intel themselves. vendors like Dell sometimes let you buy a computer with the ME turned off, via this option. various governments also pretty much always buy computers with HAP bit set by default.
me_cleaner is a separate thing that merely cleans up the redundant code; it identifies, per-platform, what code is redundant when HAP is enabled, and removes it, also shrinking the ME if you wish (otherwise it just leaves a bunch of the flash padded with all ones/0xFF).
this fact is the reason why I can provide FSDG-compliant versions of these newer Intel boards, in Canoeboot.
Thank you very much for the additional info, this is very interesting. Gives me a lot to ponder.
Do you think that T480, X1 Carbon gen 6, X280 thinkpad and other deguard thinkpads will be usable with canoeboot?
IE, blobless?
I ask for the future.
It would be nice not to have to inject blobs to get stuff working. :)
I guess I am asking, which devices you will be able to make work without blobs.
those machines you mention (t480, x1 gen6 and x280) are all either skylake or kabylake / kabylake refresh) and currently use fsp, so they are libreboot-only for now.
the sandy/ivy/haswell ones are canoebooted now because they're completely free, including raminit; no FSP for instance.
FSP replacement will probably be done at some point, however those boards you mention also use the intel boot guard, which we disabled in libreboot, but disablement relies upon modifying a specific Intel ME version, and using that, which is usually not present in your flash, so you have to extract from an old vendor update - and this means downloading it and processing it, which would therefore violate FSDG. (and libreboot does do said downloading/processing, using Mate Kukri's "deguard" utility)
it really depends on your perspective though, because the anti-bootguard hack on those boards also allows unsigned code execution on the ME, so you have a lot more freedoms, but in a manner that still technically violates GNU FSDG (which is unfortunate).
i take a rather more pragmatic overall view of things, and simply try to make the best of each board/platform - and whatever can be "perfect" goes in canoeboot.
EDIT: more context about the MEv11 bootguard disablement (intel skylake, kabylake and certain coffeelake / kabylake refresh assuming it has MEv11):
https://libreboot.org/docs/install/deguard.html
i would actually regard MEv11 as the *most free* of the MEs, in that you get that unsigned execution pretty early on. it's how the bootguard is disabled, because the exploit that enables execution is used to just make the ME pass rather than error out in its checks. (not having ME firmware at all is preferable, but MEv11 is superior IMO to every other ME-required platform at present, for this reason) - in other words, even though those MEv11+bootguard would still not be feasible for canoeboot in teh future, i would consider them as the most-free within intel hardware, once FSP is later freed. - note how in this case, "most-free" is in a libreboot-policy context, without taking FSDG into account, since FSDG does not concern itself with what's actually provided overall, but only what is distributed or facilitated by the project.
MEv11 *without* bootguard (which is also a thing on some boards, e.g. many desktop boards) would be closer to canoeboot-eligible. the question is whether those platforms run without the microcode updates, but i consider the latter test pointlness for now, until the other things can be dealt with.
EDIT2: and that is also an irony because for example, FSDG prohibits you to download and process an intel ME image in me_cleaner, resulting in fewer bytes of non-free code being present. so in the FSDG context, you have to re-use what's already in flash and not touch it, unless maybe you were to extract it yourself and run me_cleaner, which i suppose would be fine, but setting the HAP bit in the descriptor functionally does the same thing as running me_cleaner, so this is a technicality really.
That makes me wonder how far away a FSP replacement is for intel me 11 or in general.
I would be interested to know regardless. Although, also when and if those devices can be liberated.
Not needing to inject roms is far more convenient because I need a newer distro than Hyperbola to inject roms. Although I do have a devuan install on one of my SSDs.
This why I like to have two different SSD drives in my computers.
>"but setting the HAP bit in the descriptor functionally does the same thing as running me_cleaner"
I'd be interested in hearing more on this. We had a discussion on this forum a year-and-a-half ago when I was trying to decide between a System76 laptop and a NovaCustom laptop to recommend that my company buy for me to use. NovaCustom won out due to better overall pricing plus the fact that Dasharo Coreboot's HAP bit flipping seemed to be the superior method of disabling IME compared to System76's method of HECI (soft-disabling) method. Is there more information on how flipping the HAP bit compares to running me_cleaner?
yeah, just take ifdtool and do this
ifdtool --altmedisable 1 your.rom -O your.rom
this will set the HAP bit, to disable intel me
But the question is - what is the functional difference between disabling the HAP bit, and cleaning with me_cleaner? Is there any observable difference at all? You said above that there is no functional difference - are you saying that there is no observable difference in how the machine boots after disabling the HAP bit compared to a machine that's had me_cleaner run on it?
i'll have docs up on the site soon, documenting the change, which will make this clearier. just been doing other things over the last few days.
but yes:
what i meant was the what actually executes is the same in both cases. ROMP and BUP combined are the inititialisation modules. these are the ME's own boot firmware, analogous to coreboot. the "payload", by that same analogy, is then the ME kernel and all applications running under it e.g. AMT.
when you disable the ME, only BUP and ROMP are running, which means the ME initialises itself, but then it does nothing afterward. this is because certain features like TPM are still implemented and working in the disabled state.
there are three ways to disable the ME:
* ME Soft Temporary Disable, which is done from coreboot (only possible on ivybridge and sandybridge at the moment, as far as I know)
* Set HAP bit in the descriptor
* Run me_cleaner (if running on a ROM with an IFD in it, me_cleaner also sets the HAP bit)
all you need is Soft Disable or HAP. aside from this, me_cleaner also removes the redundant code that you'll no longer need. simply leaving that code in place is totally OK, but means you can't shrink the ME region for instance.
Canoeboot policy is to only distribute free software, and not steer the user toward any proprietary software. that means in Canoeboot, when you build it or use a release ROM, you simply flash the BIOS region which is all free software (even microcode is gone, and it works fine without it). optionally you can flash the IFD to do things like e.g. make regions read-write. or flash the GBE region if you want to change your MAC address.
Of course, even in a Canoeboot context, there is nothing stopping you from later dumping the flash, after Canoeboot is flashed, running me_cleaner on the dump and then re-flashing the result. This would then remove the dead code, but this step is largely optional (Canoeboot sets HAP and Soft Disable by default).
OK I see, so there's no discernible difference in functionality between setting the HAP bit or using me_cleaner, the only difference is in leaving more code behind if you don't use me_cleaner. Got it, thanks Leah!
and that is actually a huge irony, when you think about it, within the context of FSDG.
but yes, you seem to understand it. that is basically the point I was trying to make.
On my laptop I extracted the ME myself and ran me_cleaner, then flashed it. There isn't any practical difference between this and running it on a downloaded version of ME, but I wonder if it is technically FSDG-compliant.
me_cleaner itself is free software. PErsonally, I wouldn't have a problem telling people hto extract their owm ME firmware. However, that would technically be "leading them" towards it. since it's already there though, i have to wonder if it even matters?
it's a bit of a grey area, and currently something that i'm quite uncertain about.
Docs are a bit late, but they'll be up soon. The docs I'm working on don't have you extract the ME. They have you simply flash the BIOS region, skipping over the ME section entirely. They optionally have you set the ME AltDisable bit in the Descriptor(IFD) region.
to be honest, i already tell users to make a dump of their rom before flashing a new one anyway
i could make a custom path to a factory path for each target, and make that optional; if found, i could make cbmk extract IME and insert it in the ROM, by "cooking" the coreboot config just before the build.
i don't think that would violate FSDG, since you're not actually installing something new. you're re-using what you already have. and canoeboot itself would not distribute the extracted result.
my current plan, as i said in the other post, and indeed what i've implemented, is a regime where you simply avoid flashing the IME region
of course, because of this, i won't provide the shrunk ME region and enlarged BIOS region like on lbmk, because it's unknown what size the shrunk ME would be in this case. it's still possible to use the truncated file inside a larger region
i'm most likely not going to recommend extraction though. the whole point is that canoeboot is only handling free software and nothing else. since extraction can be avoided, i will have canoeboot users avoid it.
Hi Leah, I've tried Libreboot on my HP Compaq 8200 CMT using the hp8200sff target and it works even it's not listed in the docs page. Will you ever add support for this model too, please? The only issue I have with Libreboot is that it cannot recognize more than 2 drives.
probably just need to adjust the sata port map
i think you're using the 8200sff target yes?
./mk -f coreboot default
edit src/coreboot/default/src/mainboard/hp/snb_ivb_desk
tops/variants/compaq_8200_elite_sff/overridetree.cb
find a line that says
register "sata_port_map" = "0xf"
change it to
register "sata_port_map" = "0x3f"
now re-compile. see: https://libreboot.org/docs/build/
by "drives" i assume you mean sata slots, and devices in them. 3f simply enables all of them.
there are 6, yes?
00000000
this all zeroes means none enabled (binary number)
00001111 <-- that is "f"
00111111 <-- that's 3f. you see the next two bits are now 1, meaning, enable the extras.
normally you enable them selectiveyl, depending on what's wired on the board
enabling all 6 even if some aren't there is basically electrically identical to having them, but not plugging anything in e.g. not pluggin in an ssd or optical drive or whatever
anyway. try that. and tell me if that makes it work nicer for you.
of course, a proper variant could be added for your board. please report to #libreboot irc and ping Riku_V who is in charge of maintaining those HP Elite boards
> leah: i'm going full gnutard for the next month, and i'll be beating this dead horse until all the fsf community has finally upgraded from their crap x200/t400 thinkpads
>"i'll be beating this dead horse until all the fsf community has finally upgraded from their crap x200/t400 thinkpads"
[NARRATOR: thirty years later, the dead horse still needed beaten]
Upgrading to the PDP-10? It has free microcode, and you change the operation of the CPU (e.g an updated version of microcode added paging.) The microcode is loaded into the PDP-10's CPU via the front panel. Good luck finding that in anything supported by libreboot or canoeboot. Not even ARM lets you do that.
In fact, I very well could do PDP support; not sure about 10, but PDP-11 emulation is a thing, and I know for example of the https://obsolescence.wixsite.com/obsolescence/pidp-11
there is also one for 10: https://obsolescence.wixsite.com/obsolescence/pidp10
this is a commercial emulator under a free license, that you purchase and run on the kit listed there. it replicates the original PDP computers, via high level emulation.
well now. this runs on a raspberry pi, and works even on the old model 3b.
model 3b can run entirely free boot firmware: https://librerpi.github.io/ <-- I even reference librerpi on libreboot.org
the boot firmware on the raspberry pi is normally handled by a VPU blob, but cleverca ported lk (little kernel) and a bunch of code, based on previous works by christina (of the original librerpi project, which cleverca forked).
well, i've considered adding librerpi to libreboot, but concluded that it was pointless, since i already link to it on the install guide (https://libreboot.org/docs/install/spi.html)
this would also be suitable for canoeboot.
therefore vicariously, Canoeboot could theoreticalyl accomodate PDP-10 enjoyers, via high level emulation.
this is not hyperbole either. i'm being deadly serious. i added playstation support for instance (the console released in 1994):
https://libreboot.org/docs/install/playstation.html
my stated goal for both canoeboot and libreboot is to assimilate every computer ever made. i want it to run on everything. stuff from the 60s and 70s is totally fair game. all the way up to whatever the current year happens to be. i'm also looking at some pentium 2 boards to re-add, that were briefly supported, via the PCBox emulator project (see website pcbox-emu.xyz - it had some bugs at the time but that project made a lot of improvements)
Moving the PDP-10 into emulation so as to run on a machine that is less free seems to miss the point.
Then we should encourage that the emulating machine be made more free, so that we don't miss the point.
the product i linked provides actual switches and dials, and lights and everything. i once built one for a friend. (PDP-11 clone). it's really cool.
you could operate it the same way you operated the original one. the emulator underneath is immaterial. though i do see your point, somewhat, jason.
still, that's pretty cool right?
also, i cancel what i said about pentium2/pcbox - i will not be doing anything with pcbox from now on. i no longer have any wish to associate with either pcbox or its author, which never had any real practical use for my work anyway.
The idea was ditching the X200. I'm in - *if* it's for something clearly more free. Not more blobs, not blob swaps. PDP-10, anyone?
On this basis, if you also wanted a more modern machine, perhaps one of the ARM64 chromebooks would satisfy you? Canoeboot supports several of them, and they for example have libre EC firmware, and no microcode at all.
I recall you once said a CPU with free microcode beats one without - because you can change it. That's the PDP-10. Especially if we're dropping the X200 for something truly freer.
Is it? This appears to be the microcode, and it's under a clearly nonfree license.
That's DEC's microcode - It's *a* microcode, yes, but not the one I meant. ITS used its own version.
EDIT: The ITS microcode is public domain - never copyrighted. Back then, copyright had to be claimed; automatic copyright only came to the U.S. in 1989 and ITS predates that. This is a useful guide when checking old stuff like this: https://guides.library.cornell.edu/copyright/publicdomain Specifically:
1930 through 1977: Published without a copyright notice
1978 to 1 March 1989: Published without notice, and without subsequent registration within 5 years
(You'll find no registration with the U.S. copyright office.)
Isn't the file pointed by Legimet a copyright notice? If so, it looks like the row that applies is the one about a publication between 1978 and 1 March 1989 under the condition that the work was "created after 1977 and published with notice". Then, the copyright extends "70 years after the death of author" or "if a work of corporate authorship, 95 years from publication or 120 years from creation, whichever expires first".
Again, I'm not saying DEC's microcode isn't copyrighted.
OK, I didn't know that.
would you prefer that i go librebootard for a month? the upvote on your post is from me by the way, and i stand by my statements. canoeboot 25.06 rc1 coming soon!
edit: and i've now decided on a different codename for canoeboot 25.06. my policy is normally to be in sync with libreboot. this release will be special.
Yes. The new Canoeboot 25.06 codename shall be: Late Mare.
So will the new canoeboot, work on X230 thinkpad once you make changes?
Just curious.