Coreboot vs libreboot vs osboot vs Heads

Again, same answer… : Platform blobs, collaborators/maintainers/testers for faster problems resolution · Issue #692 · linuxboot/heads · GitHub
Posted in this same thread at Coreboot vs libreboot vs osboot vs Heads - #27 by Insurgo
Even the forum is telling me i’m repeating myself at this point.

Read. Then click the links. Then read again people. Please.


Coreboot can be built to create a BIOS region that would be injected into the current firmware without modifying ME (still there). This is what Skulls/1vyrain will do by default. They won’t touch ME region.

The situation for x220 (xx20) is exactly the same as for the x230 (as opposed to ME requiring only BUP as opposed to BUP and ROMP for xx30) as already answered above:

Depends of what guide you have followed and what you were trying to obtain as a final firmware image. Some guides refer to extracting the VBIOS instead of using coreboot native graphic initialization. Depending of what you followed, you probably extracted the VBIOS, where you could have booted with native graphic initialization, native memory initialization, without microcode updates.

Basically, on the x220 (same applies to all xx20: t420/w520/x220 and some other sandy bridges) and xx30 (t430/w530/x230 and others)

  • the Embedded Controller (EC: controls keyboard, temperature LEDs, etc) is binary blob driven (upgraded through Lenovo firmware prior of flashing coreboot)
  • ME (if you want to neuter it, you need to backup firmware, clean it and flash it back). Optionally, you would want to use that freed space for more interesting purpose. This is what Heads does.
  • VBIOS: if you want to boot Windows, you have the option to use coreboot native initialization + Seabios’s coreboot payload without backuping, extracting the VBIOS from backup, injecting the VBIOS back into coreboot prior of compilation. More information at Skulls project on that.

So on a binary blob needed at compilation: the xx20 doesn’t need any.
On the binary blobs required to boot the x220 from initialization:

  • Functional EC controller
  • Microcode on die (in CPU. Preferably apply microcode update for security (Qubes will do this if you don’t in firmware anyway))
  • ME (BUP) (xx30 requires BUP and ROMP)

That’s it.

Then of course… The binary blobs elsewhere:

  • iGPU/dGPU firmware
  • Ethernet firmware
  • Wifi firmware. binary drivers (depends of user choice)
  • Firmware on SSD/HDD drive (there is OpenSSD project but still research)
  • Firmware on sdcard, sdcard readers, usb keys, usb dongles and any other peripherals you use

Firmware everywhere, binary blobs everywhere else.

2 Likes