Coreboot vs libreboot vs osboot vs Heads

User Support
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.

41

RE:

42

Post from 2016 on why libreboot doesn’t work for Qubes here: Research support for libreboot/coreboot-based systems · Issue #1594 · QubesOS/qubes-issues · GitHub

43

Thanx for detailed answer, and apologies for not reading previous posts carefully. For me it was hard to figured everything out by myself since fragmentation of the coreboot project to many flavors, and not much experience with all the components of mainboard firmware.

44

That may be what needs to be tackled with exactly: what coreboot fragmentation is “perceived” here?

I repeat: coreboot is the native initialization code to do basic stuff here. It requires user knowledge to provide such configuration to enable/disable features (including virtualization etc, just like you would do in your BIOS menus) either at build time, or later on through runtime configuration (needs knowledge and tools).

Then, skulls/libreboot/osboot/Heads are “users” of coreboot. Those build systems provide specific coreboot configuration to attain their goals, defining which payload they include, and tweaks to accomplish what they want to accomplish.

Most of those coreboot distributions will pack either Seabios/Grub as their payload. Depending if the user wants to boot windows, the coreboot configuration will need to point to additional binary blobs (vbios) either into coreboot or in the payload. (Read Skulls, they explain it good). Libreboot will obviously not include them, since their goal is to boot open source distributions from a firmware that doesn’t include closed source produced binaries either. Osboot has a more liberal policy, Skulls give you the choice, and Heads boots linux only through kexec calls. That is, Heads is a linux payload, and kexec’ into another linux kernel without any “bootloader”, meaning it reuses linux drivers and tools to not include other tools in the possible attack surface at boot.

So to make sure this is addressed once and for all: as long as coreboot will not distribute default configurations for all the possible use cases out there (they won’t), users need to prepare such configuration (text file) for their use case or rely on configurations provided online, and depending on their use case, will have to follow extensive guides to backup their firmware, extract some blobs, do some cleaning on them if desired, and then put them where coreboot expects them for coreboot build to succeed.

Skulls/libreboot/osboot/heads/1vyrain cannot distribute (host them in their repositories) directly most of the blobs required for legal reasons (blobs redistribution policies being restrictive, project owners could be pursued in justice) but can provide tools, scripts (build systems) and outcome ROMs for their defined use cases (you can download blobs as part of other projects or extract those blobs from online available binaries.) Those projects just to the magic of downloading them and putting them at the expected configuration place.

At the end of the day, from technical perspective, when the build happens, coreboot (either reduced by libreboot so no blobs is on the local drive or full) is used to build the provided board configuration, which states which binary to depend on or not, tweaks to be applied, and produces either the final ROM or parts to be assembled by the coreboot distribution after coreboot built platform corresponding ROM. Then, if coreboot configuration was not telling how to stitch final ROM together, the build system (scripts) will apply the final stitching glue to put all pieces back together (nvramtool, cbfsutil, ifdtool, me_cleaner and more).

The coreboot distributions/build systems exist to hide such details, to produce desired outcome without everybody needing to know those details.

Using coreboot directly is always possible. You coukd build coreboot without blobs today for a x200, without blobs and without microcode update. Would that be exactly an equivalent of libreboot? Maybe/maybe not. Could you use their support channel if something goes wrong? That would be highly impractical since too many variables would be in play to try to find out where things went wrong. This is where distributions play their role: they take upstream code version, use it to produce a supported outcome, and interact upstream if issues are found so the whole ecosystem is benefited.

3 Likes
45

Ok, now its even more clear for me. As a regular person that is not a target for APT, and not a libresoftware fanatic I will be satisfied if someone port Heads to one of Lenovo Legions.

46

Once again…

That would require coreboot to support such boards.
Then and only then for coreboot distributions to add blobs download scripts, update documentation, own those platforms, decide to maintain them.

As you can understand, those boards need to fit into the coreboot distribution goals.

As you should have understood by now, and I won’t repeat myself anymore:

  • libreboot won’t add it. Blobs.
  • Heads might never include it if blobs added cannot be justified from security perspective

First coreboot distribution that will include such board would be osboot after such board is supported under coreboot, not before.

Why osboot, you may still ask?
Because osboot goal is to provide rom and minimal blobs required for all supported coreboot platforms

That is not the goal of any other coreboot distribution i’m aware of.

Consequently, that part of the discussion should be addressed

  1. With coreboot
  2. When/if coreboot supports it(who will pay for that port) then this should be discussed with osboot
  3. Then if integration under Heads is justifiable (Qubes HCL?) Then maybe it will be integrated/ported from osboot into Heads

Heads does not have a goal to support each and every coreboot supported plateform. This is the goal of osboot.

Coreboot has not a goal of supporting ($$$$) each and every laptop/server/workstation out there. The support is enabled by platform interest, profitability, and availibility and reputation of such platform, amongst many many other things. Each consumer would want some platform to be supported by coreboot for so many different reasons. But this is not how things work. Similarity to other existing ported platform is one major enticement to do a port. Sturdiness, easy to repair, accessibility of SPI chips etc are all important factors into deciding to port a platform to coreboot. And are discussions that should happen with coreboot (After having contacted your personal Angel Investor to convince him to pay forbthat non-existing coreboot port, not before! Coreboot mailing list/issue tracker woukd otherwise turn you around for the same reason i’m becoming impatient in this thread: support is expensive. Board inclusion requires initial investment. The first answer you would get from coreboot here would be “Nothing against Lenovo Legions port: who will pay for this port? You?”

As far as i’m concerned into the present discussions, I am not interested into representing all projects here. My goal is to address how things work so that Qubes end users understand the differences between closed source firmware, coreboot firmware (and ever increasing blobs and user lock down, right to repair) and more globally the problems that are increasing in pace in terms of blobs reliance and the losses not yet perceived in terms of rights to openness in the industry

I feel that people are happy to consume new stuff, but are not aware of the costs in terms of freedom, openness and user ownability of such platforms.

I have no clue what a Lenovo Legion is. I have no interest into looking up the specs in terms of chipsets included, subtleties of that specific platform and the other 100 new ones that were released in the last months or so.

I’m interested into giving thinking frameworks to Qubes users so that they understand that there is no such thing as an open source coreboot supported platform marketed after 2013. No Intel board without ME after 2008. No AMD board without PSP/AGESA after fam15h. No OpenPower completely open hardware after Power9. No ARM produced platforms without Trustzone and other blobs….

I am not interested into models and who is better between AMD/Intel without addressing the status quo.

I am interested in getting the community aware of the elephant in the room and getting them the tools to ask for what they want, after they realise that it’s not produced/manufactured anymore.

And most importantly, i’m interested into giving them back their voice (voting?) where this matters:

1 Like
47

It is only my wishful thinking. I know that it will be much work since I google a bit about how to start porting coreboot to a new platform and find out that if there will be some similar platform it is way easier and probably I could try to that in that case. But when you have to do it from the scratch and identify every single chip on the board first, it will be rather a task for a full time job and probably not for one person. So yes I understand that it may never happened. Once again thanks for making things more clear.

P.S. Only thinking of Legions since they are rather popular among people I know (most of them are devs of some sort). I’m using Qubes on such machine from about a year and not encountered any serious issues, performance is also good. There are some versions in Qubes HCL but I think they are not so popular among Qubes users (don’t know exactly why, maybe it is a closed circle and the problem is lack of coreboot support).

48

Note that osboot has been merged under libreboot this past weekend.

This will confuse everyone even more.

49

I understand that this means that Qubes already deals automatically with all available microcode updates and I do not have to worry about that, which is extremely good. Many thanks!

But another question arises from this very long and interesting thread:

I have three corebooted computers:
KCMA-D8 with Opteron 4284
W520 with Ivy-Bridge
X230

Do you know which one received more microcode updates from Qubes or has less vulnerabilities, so that it can be considered reasonably safer?

Many thanks for reading