Coreboot vs libreboot vs osboot vs Heads

[Insurgo]

@tanky0u

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

RE:

@Insurgo

Concepts mixed here again.

Heads/skulls/libreboot/osboot are different coreboot build systems (distributions), aimed at producing ROM images based on different coreboot configurations (different features, different payloads, different mandates and goals).

[Insurgo]

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

[Szewcu]

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.

[Insurgo]

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.

[Szewcu]

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.

[Insurgo]

@Szewcu

I will be satisfied if someone port Heads to one of Lenovo Legions.

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:

@Insurgo

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:
FSP 2.4: runtime blobs! - coreboot - mail.coreboot.org

It’s referred open letter (please sign) to ask Intel to respect their promise to open source FSP:
Adopting Open Source Firmware Approach for Intel FSP

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

[Szewcu]

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).

[Insurgo]

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

This will confuse everyone even more.

[Franz]

@Insurgo

Those microcode updates are applied either early, by the firmware (in stock bios updates) or through OS updates (Qubes apply them as well if existing for the platform).

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