Coreboot vs libreboot vs osboot vs Heads

User Support
21

How can we create a system for risk classification of firmware/driver components which is similar to the
CVE/CVSS system for identifying vulnerabilities for apps and software closer to the user.

22

We would need a list of all the coreboot/heads firmware/drivers included in the image to have a real
idea of the attack surface. Can somebody provide this? cbfstool is run from the heads recovery shell?

23

And then having a list of the binary blobs included in the coreboot/heads image and ranking them based on risk (cpu microcode being amongst the lowest risk).

24

Sounds like a waste of time if you ask me, but you can go through the source yourself.

coreboot

coreboot 3rd party blobs

1 Like
25

All of these 3rd party blobs are included in every payload?

26

As of now a complete cbfstool is not provided inside of Heads, no. Through the addition of GBE Ethernet randomization, I successfully packed ifdtool inside of a PR here: WiP change Intel PHYsical mac (gbe) from Heads by tlaurion ¡ Pull Request #1195 ¡ linuxboot/heads ¡ GitHub. A limited version is included though, permitting to extract files from within heads through a more limited cbfs tool that was added through flashrom tools a while ago, which purpose is to add/extract files from cbfs: heads/modules/flashtools at master ¡ linuxboot/heads ¡ GitHub

Adding a feature complete cbfstool could be added the same way as ifdtool under referred PR to have cbfstool compiled by the cross compiler to have it packed under initrd and made available to Heads recovery shell.

But as far as you might be interested, you can see what is compiled at compilation time.
At the time of writing this, CircleCI latest build output shows you the content of cbfs as packed by coreboot build system in Board Output of each commit compiled board roms.

Examples for latest commit at the time of writing, as explained under Step 1 - Downloading Heads | Heads - Wiki

Direct Board compile output (it will open to cbfstool output directly):

For xx20/xx30:
You can see from CircleCI/local builds the output of xx20/xx30 blobs downloading/ME neutering blobs on each builds. This happens prior of platforms being built so that the blobs in question are downloaded from Lenovo binaries and put where expected by coreboot for Heads. This happens in the prep_env step https://app.circleci.com/pipelines/github/osresearch/heads/446/workflows/53d5397c-7eeb-41f4-a441-a2ac4dc212c7/jobs/4553, which calls the scripts individually:

1 Like
27

Unfortunately, looking there won’t help you a lot…
Coreboot, in its standard way of building, will compile only the BIOS region, which is meant to replace only IFD’s BIOS region (leaving GBE and ME region untouched, just as Heads describes its legacy builds here Prerequisites for Heads | Heads - Wiki). That results into coreboot building a “fake” IFD record for completeness, and would result in a brick if flashed externally. This is why Heads/Skulls/1vyrain describes flashing instructions into only produce/modify the 4mb chip of xx30 (t430/x230/w530/t530/others).

This is why “Maximized builds” were created: to dodge the blobs redistribution legality problems: github doesn’t host them. They are downloaded from the CI/local builder’s computer to build a final ROM that is feature complete and can be flashed internally/externally.

The legal problem is then in the hands of the person flashing the device where things are pretty confusing here. Why are those blobs provided inside of ROMs downloadable for ChromeOS/Lenovo/manufacturers? Why is it legal for a user to backup, extract those blobs from a local flash backup, and then injected into a local build of coreboot but could not be done from a script on a CI platform? I took a stance and put that magic online after realizing that those blobs were directly available from Lenovo downloadable .exe images.

Osboot borrowed the same principles and decided to permit to build complete ROMs in their build system as well, including not only coreboot’s distributed microcode (permitted redistributable blobs), but also ME, GBE (generated config blob) and MRC (memory initialization blob) as well based on Heads prior work. They thanked prior work under Integrate T440p Support from Osboot · Issue #1133 · linuxboot/heads · GitHub

Coreboot does not have the “right” to legally redistribute ME, nor MRC blobs for older platforms, because of blobs redistribution issues (Intel not having explicitely permitted to redistribute those blobs is a grey zone where everybody is still inconfortable, therefore not being under coreboot-blobs since that issue was never resolved and Intle just adds more blobs under FSP).
This was tackled extensively under Provide IFD, Gbe and ME blobs ¡ Issue #307 ¡ linuxboot/heads ¡ GitHub prior of Maximized builds being born under Heads.

If you are interested in the issue of blobs and FSP, you can participate in the debate:

No…
Please read Platform blobs, collaborators/maintainers/testers for faster problems resolution ¡ Issue #692 ¡ linuxboot/heads ¡ GitHub

Above post should also clarify and give insights on where to spot them on.
If you want better blobs transparency on coreboot level, I would strongly ask engagement from Qubes community to comment upstream on this coreboot merge request to ping its advancement https://review.coreboot.org/c/coreboot/+/32237

Another place to look at the have a hint on the to-be-added-blobs is the coreboot mailing post:
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/5RLQ3YTOTM37F2T7YLJPBTGZXYATBEI3/

It’s referred open letter (please sign) to ask Intel to respect their promise to open source FSP:
https://openletter.earth/adopting-open-source-firmware-approach-for-intel-fsp-59d7a0c6

And open issues on github to question Intel on their plan for FSP, which is closing down what coreboot will be able to initialize in the future: FSP loading SMM ¡ Issue #37 ¡ UniversalScalableFirmware/documentation ¡ GitHub

2 Likes
28

So the real “black box” here in terms of blobs is Intel FSP? Is that the gist of it?

29

Are ARM Soc’s any better in terms of firmware freedom? RISC-V?

30

As far as I know, manufactures of Intel based laptops are given the FSP source code, and can build their own package.

31

They are given the source code, ok, and then the necessary binaries are compiled with it? Does that
mean Coreboot gets the FSP as a blob from Lenovo for example?

32

Is it possible to avoid using FSP by way of compiling open firmware (OFW as a Coreboot Payload - OpenBIOS) as a coreboot payload or just by switching to ARM instead of x86?

33

Not sure if there could be any 100% blob free coreboot distro for x220 and newer machines. Since even when I investigate with my cousin using coreboot on his x220 there was one blob that was recovered from the original BIOS, and one downloaded from vendor site an cuteddown. For other machines that I investigate there was also some blobs by default, also you can’t get rid of modern Intel ME completely without bricking your PCI.

34

what did you use to analyze this, cbfstool?

35

Just read the manuals. In guide for x220 and other supported laptops there is brief overview which blobs it’s using. If You read more about me_cleaner you will find that neutralizing me today is only removing some modules from it and gently asking to disable. Without it strange things can happen.

36

Are they any works currently on porting coreboot to more recent consumer laptops? Or whole development now is about chromebooks, system76 and security focused custom machines? When I digging in (half a year ago) it looks like newest supported Lenovo was X1 Carbon gen1 (and we have gen 9 now I think), and there was no Legions at all.

37

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.

38

I have re-read Libreboot – Binary Blob Reduction Policy

This basically is the state of coreboot configuration possibility, which if no binary blob is required to boot the platform, it should not be used. Heads is doing the same.

So the platform configuration defines what blobs are required as my prior answer. So if you want to have a w530 and enable its dGPU and iGPU, then you will need the dGPU blobs. And by choosing to use such platform, and having read the blobs directory documentation, you should be aware of it, just by understanding the board name there, while reading its associated coreboot configuration, be aware of what blobs you are accepting: heads/config/coreboot-w530-dgpu-K2000m-maximized.config at master ¡ linuxboot/heads ¡ GitHub

But as also stated elsewhere, there is some “dark magic” at play there to try to simplify things everywhere. Therefore, if you look at Librem5v4 coreboot config heads/config/coreboot-librem_15v4.config at master · linuxboot/heads · GitHub you might be misled into thinking there are no FSP blobs required. Unfortunately, those are now taken care into coreboot build system, which was not the case before, and looking at the outcome of the build will show you that they were included into the ROM.

This is why, again, I would advocate everyone in this thread who are interested into the increased binary blob needed to be included into coreboot to push developers into stating them clearly. There would be a really practical places to do so:

You can take action on this, and should.

39

I am profoundly confused on why those questions are just asked with different words, but being basically the same questions over and over.

So my understanding of the question is that people want “newer” Lenovo laptops supported. But… that also seems to mean “with the same level of openness/user control/absence of blobs as before” which is simply not possible anymore, and that seems to be the mental blocker to accept the simple answer: “that level of openness/user ownability/user control/absence of blobs is not possible anymore”.

I think that that answer “That level of opennesss won’t happen anymore” is difficult to absorb/accept when put as clear as that, which is why that question is asked over and over, while people expect a different answer to magically be said. But that won’t happen magically, which is what I keep answering over and over.

I think the reason nobody invested time/energy/money into porting newer Lenovo to coreboot is mainly because of this. The build quality of what was IBM ThinkPads before (X60/X200/T400) when Lenovo brought the ThinkPad division, was in an era where reversing those really high quality builds, combined with their returns on investment for openness, was making them come to life.

If we look at the T440p, which could support 32Gb of RAM, if the required MRC blob was reversed, shows some lack of interest from companies that paid for the ports to coreboot to happen in the past.

That is my insights on why we don’t see newer Lenovo being ported to coreboot.

Now, if we take the release notes of coreboot 4.17 alone, we see the addition of:

  • Star Labs laptops
  • Clevo laptop

Yet again, those, as any other laptops, will require FSP blobs, ME with possibility of being deactivated (no module removed), where System76 for example made some important efforts to reverse and open the EC firmware. But coreboot is loosing configuration capabilities at initialization.

FSP/AGESA are evolving in such way that coreboot dependency on those blobs is becoming total, and coreboot capacities to revert some configuration done by FSP/AGESA is becoming more and more limited over time.

This means, in practice, that blobs are now exclusively doing

Basically, even today, coreboot is misunderstood.
And consequently being cornered.

This is happening slowly since Intel FSP existed:

We are talking of nearly 10 years of advancement into closing down control on our platforms
I know some of you hate GitHub, but I would appreciate propositions on editing the first post Platform blobs, collaborators/maintainers/testers for faster problems resolution ¡ Issue #692 ¡ linuxboot/heads ¡ GitHub which goals into all of this, pointing to the right upstream places to be able to understand current states of things. What is missing there?

40

For X230, you can’t do libreboot. You gotta go with the coreboot.