Yabits: A New UEFI Coreboot Payload Alternative To TianoCore & Closed-Source Blobs

[starshipeleven]

And why we - as the open source enthusiasts - should care about what crap the bloated proprietary UEFIs are using to boot the things?

Because Coreboot isn't using different crap to boot the things on anything remotely new. It's not "open source" anymore, Intel killed it.

Coreboot is still using the FSP blobs from Intel, that are technically smart enough to be able to boot a u-boot bootloader from flash on their own (i.e. Coreboot is basically a shim in this case).

LinuxBoot just avoids having to sign NDAs to get info and all the board hardware reverse engineering phase as it reuses the same pre-configured low-level components extracted from stock firmware.

there are modern boards: check out Purism Librem and Librebox

They aren't using SeaBIOS though. Heads firmware does not use SeaBIOS, but a Linux kernel+userspace.

The ones using real Coreboot+SeaBIOS (although not by default afaik) are Chromebook/boxes, but still, blobs (the FSP).

And, actually even those proprietary UEFIs could use SeaBIOS as a module

Why tho? They usually have CSM mode to boot in "bios mode".
UEFI isn't disabled if you boot in "bios mode". It's still running and has SMM access.

It might be useful for future UEFI firmwares where they drop CSM mode (as they will do so, there were some statements about it).

Check out "vboot" source code directory

what vboot project? Can you link to it?

and also "heads" project, to realize that your coreboot+SeaBIOS combination could be made secure if you would like

Can I point out that Heads project is not using SeaBIOS but is booting a Linux kernel + small embedded OS from the SPI flash to act as a powerful and smart bootloader (which is required to do all the signature checking and stuff using the TPM without having to reinvent the wheel multiple times)?

Heads is working like LinuxBoot, and its main dev is also active in the LinuxBoot scene. It is just using Coreboot for low-level initialization instead of reusing stock firmware blobs. This is of course possible only where you can add true Coreboot support to begin with.

[R41N3R]

And reflash your BIOS every time there's important Linux kernel update? Not only that wastes time, also it's wearing out the SPI flash. Why not use SeaBIOS to boot to your favorite Linux?

I do use SeaBIOS for VM's as well. But for real machines it would be nice to have something else that works in reality, CoreBoot is too rare, sadly. Only had one Chomebook with CoreBoot and SeaBIOS some years ago. But most of the machines will never get CoreBoot, in this case LinuxBoot sounds much more realistic.

[michaelb1]

coreboot is still using the FSP blobs from Intel, that are technically smart enough to be able to boot a u-boot bootloader from flash on their own (i.e. Coreboot is basically a shim in this case)

Luckily there are some AMD platforms supported by coreboot, and that should be our priority because coreboot is dead at Intel (being "just a shim" sucks)

They aren't using SeaBIOS though

It might be useful for future UEFI firmwares where they drop CSM mode (as they will do so, there were some statements about it)

Sorry but I can't understand why we need to drop CSM or why we can't use SeaBIOS. Last time I checked, there were no operating systems that were UEFI-only. Why should we discard something that works really great, especially since UEFI feels like a "bloated/beta" compared to a good old BIOS

what vboot project? Can you link to it?

https://github.com/coreboot/vboot

Can I point out that Heads project is not using SeaBIOS but is booting a Linux kernel + small embedded OS from the SPI flash to act as a powerful and smart bootloader (which is required to do all the signature checking and stuff using the TPM without having to reinvent the wheel multiple times)?

Is there any reason why SeaBIOS can't be used in this scenario? Compared to a Linux kernel (lines-of-code metric), SeaBIOS is much less bloated and security audit is really possible there (for those who care)

[starshipeleven]

Luckily there are some AMD platforms supported by coreboot, and that should be our priority because coreboot is dead at Intel (being "just a shim" sucks)

AMD has AGESA blob (a dumber and simpler counterpart of FSP, but it's still a blob) for anything new, and its support kinda sucks and lags behind.

Sorry but I can't understand why we need to drop CSM

Because it adds BIOS unsafe-by-design on top of UEFI issues? CSM is the worst of both worlds, it was there just to ease the transition (so people don't have to throw away all hardware) but it was bad, very bad.

That said, look here: https://www.anandtech.com/show/12068...m-uefi-by-2020
By next year Intel removes CSM from UEFI standard, so newer devices will not have it within a few years. And yes there are already UEFI-only devices, usually embedded/industrial or tablets.

And yes, that means network cards, GPUs and RAID cards without UEFI support will not work on new systems. That's one of the main reasons CSM was made. Nowadays this hardware is kind of old (5-ish years old) so it's not going to be a particularly big issue.

or why we can't use SeaBIOS.

Because it's a payload of coreboot, and as already said, coreboot is a dead end.
And also because it's unsafe as fuck. Loading the MBR's bootloader area in RAM and executing it no questions asked has never been particularly safe. That's what BIOS standard mandates, and what SeaBIOS does. There is no "secure boot" or "signature enforcement" capability, this is not acceptable for something modern.

https://github.com/coreboot/vboot

Ah ok that's the ChromeOS's bootloader. That's still a coreboot payload though, not a standalone thing, so the main issue remains, coreboot is a dead end.
This is a more human-readable explanation of vboot for those following from home https://www.coreboot.org/git-docs/Intel/vboot.html

U-boot (which is a standalone bootloader that can be loaded directly without Coreboot) can do that too, with FIT kernel images https://github.com/u-boot/u-boot/blo.../signature.txt (yes what they wrote in the "introduction" isn't 100% up-to-date, if you scroll down you see that with some hardware storage for keys, like a TPM or somesuch it actually offers non-UEFI "secure booting" capability).

Is there any reason why SeaBIOS can't be used in this scenario? Compared to a Linux kernel (lines-of-code metric), SeaBIOS is much less bloated and security audit is really possible there (for those who care)

See above or ask them if you don't believe me.
Please note that the linux kernel inside Heads has pretty much everything disabled so its actual LoC isn't particularly large (features disabled will not be compiled, any bugs in code that isn't compiled won't affect the final product).
For example they don't enable multicore or ACPI support in their bootloader stage.

Linux is still offering things that would require them to reinvent wheels like network stack for network boot, and also a route for easy addition of any feature the Linux kernel can do if required (just enable the relevant compile option), plus it's maintained by third parties, which is a massive force multiplier for a project like this.

Their rationale in LinuxBoot was that the Linux kernel is not a new project and it is already receiving audits. Adding a new project or using another project that is far less interesting than Linux kernel would mean anyone doing audits will have to care enough to do it, and will also need time to familiarize with a different thing.
So using Linux kernel is a way to "build on the shoulders of giants".

[michaelb1]

Because it adds BIOS unsafe-by-design on top of UEFI issues? CSM is the worst of both worlds, it was there just to ease the transition (so people don't have to throw away all hardware) but it was bad, very bad. ... And also because it's unsafe as fuck.

Sorry but why do you think that UEFI is more secure than BIOS ? Compared to "good old BIOS", any UEFI has a bloated source code with a much larger attack surface, and it is extensible-by-design so its' quite easy to extend it with a malicious module, and also since the big majority of computers are running UEFI nowadays its' a primary target for malware, including the malware being created by state-sponsored actors.

Because it's a payload of coreboot, and as already said, coreboot is a dead end.

I don't see any technical reasons why SeaBIOS couldn't be made a payload of anything else except coreboot. Using a Linux kernel, when a SeaBIOS is available, seems to me as a bit of an overkill. Any "network stuff" is also possible with SeaBIOS thanks to it iPXE module

There is no "secure boot" or "signature enforcement" capability, this is not acceptable for something modern.

But that "vboot" is not limited to ChromeOS devices, and it could be used in a coreboot+SeaBIOS+vboot combination: so yes, it is possible to have a "secure boot without UEFI".

Ah ok that's the ChromeOS's bootloader. That's still a coreboot payload though, not a standalone thing, so the main issue remains, coreboot is a dead end.

After vboot gets mature I expect it to become a default component of any coreboot. But does it matter that currently its' a standalone thing? Anyone who wants a "secure boot" together with their coreboot+SeaBIOS could get this vboot without a problem (although with a few extra commands)

[starshipeleven]

Sorry but why do you think that UEFI is more secure than BIOS ?

I never claimed so. I said that having a UEFI system run in CSM is actually worse than running it in UEFI. There is no limits to how bad something can get, you know.

it is extensible-by-design so its' quite easy to extend it with a malicious module

BIOS was also "extensible" too, in a more crude and BIOS-vendor-specific way, but you could add modules for additional functions, or change configuration of existing ones.

Both BIOS and UEFI rely on measures that prevent writing on flash or firmware signature enforcement to prevent tampering.

I don't see any technical reasons why SeaBIOS couldn't be made a payload of anything else except coreboot.

Everything is possible, but raw booting an embedded Linux was basically free (as Linux kernel can be booted directly like that already, they just made a shim to make it look like a EFI module), more easily extensible if required (it can boot from any storage device the Linux kernel has a driver for, like NVMe for example, can use any crypto, any networking protocol, any embedded device protocol, anything else) also basically for free (as the support for most features and hardware is added and maintained by upstream, while SeaBIOS requires them to add support for anything more than USB, Sata and basic network boot), and has 0 amount of legacy BIOS crap they don't need.

But that "vboot" is not limited to ChromeOS devices,

It is limited to Coreboot ones, which basically means ChromeOS devices, and maybe some embedded and industrial system product line.

it is possible to have a "secure boot without UEFI".

As said also Uboot and LinuxBoot can do that, and the main selling point of LinuxBoot is that porting a new x86 board is actually possible without paying and signing NDAs with Intel.

After vboot gets mature I expect it to become a default component of any coreboot. But does it matter that currently its' a standalone thing? Anyone who wants a "secure boot" together with their coreboot+SeaBIOS could get this vboot without a problem (although with a few extra commands)

Are you aware that it's impossible to port coreboot to anything newer than Ivybridge without an NDA and paying Intel for access to docs and support?

And that even to reach support for Sandy and Ivy bridge they had to work with leaked information from some OEM?

[michaelb1]

BIOS was also "extensible" too, in a more crude and BIOS-vendor-specific way, but you could add modules for additional functions, or change configuration of existing ones.

Indeed, in BIOS case such attacks have to be targeted at the specific hardware (and therefore more costly when you need to target many people), while with UEFI it should be much easier to write a more universal malware that could affect many PCs.

Both BIOS and UEFI rely on measures that prevent writing on flash or firmware signature enforcement to prevent tampering.

In the case of state-sponsored actors it doesn't matter, it could be that major BIOS making companies are already required to share their private signing keys with some three letter agencies.

Everything is possible, but raw booting an embedded Linux was basically free (as Linux kernel can be booted directly like that already, they just made a shim to make it look like a EFI module), more easily extensible if required (it can boot from any storage device the Linux kernel has a driver for, like NVMe for example, can use any crypto, any networking protocol, any embedded device protocol, anything else) also basically for free (as the support for most features and hardware is added and maintained by upstream, while SeaBIOS requires them to add support for anything more than USB, Sata and basic network boot), and has 0 amount of legacy BIOS crap they don't need.

I understand your reasoning and I love Linux. But I don't want updating my BIOS every time a new Linux kernel came out with important security fixes, and SeaBIOS has about just 50k lines of code total, of which a few thousands could be active depending on a specific configuration. And its' very easy to add the new features there, btw I just wrote one SeaBIOS feature today - multiple ramdisks support - and would be sharing it soon. I'm not sure any possible alternatives could be this small and beautiful. It is impossible to strip Linux kernel to 50k lines.

It is limited to Coreboot ones, which basically means ChromeOS devices, and maybe some embedded and industrial system product line.

There are a lot of coreboot-supported devices which aren't Chromebooks. Yes, many of these devices are at least 5 years old, but luckily it seems that the priorities of the computer evolution have been shifted from "more performance" to "more energy efficiency", and as result the relative performance difference between the 2018 and 2013 PCs is much smaller than it was between 1990/1995, 1995/2000 or 2000/2005. 2013 PCs could be considered modern by the scope of tasks they are able to perform.

As said also Uboot and LinuxBoot can do that, and the main selling point of LinuxBoot is that porting a new x86 board is actually possible without paying and signing NDAs with Intel.

My main concern here (which is probably a concern of many other coreboot'ers also) is that the corporations do not want to keep benefiting the "small guys" running coreboot on their domestic PCs by improving the coreboot's common source code, because the "small guys" do not pay any money to the corporations. Also there's probably a NiH syndrome. So the corporations would like to switch to their own thing, be it Yabits or LinuxBoot or anything else. And it seems highly likely to me that this "own thing" will be either closed source / BSD licensed with the important things kept as internal closed source, or the support will be limited to a particular set of corporative hardware (e.g. Facebook servers)

Are you aware that it's impossible to port coreboot to anything newer than Ivybridge without an NDA and paying Intel for access to docs and support?

And that even to reach support for Sandy and Ivy bridge they had to work with leaked information from some OEM?

Yes, I am aware of that, but I don't have any Intel PC: all my computers are coreboot-supported and AMD-based. Probably my next workstation would be not-x86-based, e.g. Talos II, because the modern x86 seems to be doomed in freedom aspect.