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

[starshipeleven]

This is currently able to boot 32-bit x86 UEFI images (unverified, 32-bit OSes that have UEFI on install media are magical unicorns and very difficult to find). The big problem with BIOS boot is the MBR that is embedded in the boot sector, and the fact that the boot sector has to be 512 bytes. This limits the allowable disk size to 2TiB. Meaning that if you get a 3TB disk, you can't BIOS boot it without doing some nasty fake protective MBR stuff, then using whatever actual partitioning scheme you want to use.

Afaik you can boot GPT drives in a BIOS system fine if you use GRUB https://en.wikipedia.org/wiki/BIOS_Boot_partition
It's not nasty at all, GPT has a "protective MBR" by default, and GRUB writes there its first stage, you just needs an additional "BIOS boot" partition where it can store its second stage (which was all written in the MBR in true MBR drives where there is much more space there than just 512 bytes)

What is horrible is the "hybrid MBR", which is an entirely different level of haxx. http://www.rodsbooks.com/gdisk/hybrid.html

Also Windows bootloaders are horrible, and windows won't install itself in a GPT drive if it's not booted in UEFI, although you can workaround this https://www.aioboot.com/en/windows-10-gpt-legacy-bios/

[GI_Jack]

Yabits, like Tianocore, is pointless. SeaBIOS - the default coreboot payload - is good enough, and also its' better than UEFI regarding the security (thanks to UEFI extensible nature its' relatively easy to extend it with a malicious module)

As opposed to what? blindly executing the first 440 bytes of a given hard disk, and expect it to not be malware or chain to malware? BIOS is not good enough. Being chained to a reverse engineered proprietary technology from 30 years ago made into a standard is not "good enough".

[Weasel]

As opposed to what? blindly executing the first 440 bytes of a given hard disk, and expect it to not be malware or chain to malware? BIOS is not good enough. Being chained to a reverse engineered proprietary technology from 30 years ago made into a standard is not "good enough".

Don't boot from an untrusted hard drive then.

[chithanh]

TThe big problem with BIOS boot is the MBR that is embedded in the boot sector, and the fact that the boot sector has to be 512 bytes. This limits the allowable disk size to 2TiB. Meaning that if you get a 3TB disk, you can't BIOS boot it without doing some nasty fake protective MBR stuff, then using whatever actual partitioning scheme you want to use.

This is wrong on all accounts.

For one, partition size is limited to 2³²-1 sectors as the length field in the MBR is 32 bits. That means with 512 byte sectors you have almost 2 TB. If you have 4K native drive, then it is 16 TB.
Then you can have two partitions, one primary starting at the beginning of the drive and one extended at sector 2³²-1, both 2 TB in size. This must work with any conformant implementation (though in practice you can run into problems). That way you can use almost 4 TB with MBR and 512 byte sectors.

Afaik you can boot GPT drives in a BIOS system fine if you use GRUB https://en.wikipedia.org/wiki/BIOS_Boot_partition

There is even a standardized method to boot GPT on BIOS systems, described in T.13 EDD-4.
GRUB however uses its own proprietary method instead of the standardized one. Syslinux gptmbr.bin for example implements T.13 EDD-4 to boot from GPT on BIOS systems.

[rene]

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?

you could kexec the latest kernel w/o reflashing, … ;-)

[Min1123]

This is wrong on all accounts.

Interesting. I'm happy to hear that the 512B emulation is now gone for modern drives and it's interesting that the size has been kicked down the road to 16 TB-ish for now, but I'd be interested in your preferred method with Linux now.

MBR + a few primaries + extended
MBR + a few primaries + LVM
GPT + gptmbr.bin

Something else?

I normally GPT and boot UEFI with a 64MiB EFI part in FAT32, a 512MiB Boot in EXT4, and then a large thin provisioned LVM or a BTRFS in one partition. I've been burned by distros getting larger, so I don't keep my root partition and my home partition separate anymore, preferring to keep most data on a remote SAN and temporary data that's easily replaceable (test VMs, source clones from GIT, miscellaneous ISOs) on a local HDD.

[chithanh]

Interesting. I'm happy to hear that the 512B emulation is now gone for modern drives and it's interesting that the size has been kicked down the road to 16 TB-ish for now, but I'd be interested in your preferred method with Linux now.

4Kn drives have come to market (started with drives inside USB enclosures, and now also SATA). But they will not displace 512e drives any time soon.

GPT + gptmbr.bin

That is what I use on BIOS systems which don't have to dual-boot.

[michaelb1]

But with SeaBIOS can you boot from eMMC, NVM Express? Can you boot M.2 devices?

Boot devices support here depends ONLY on coreboot. If a specific coreboot implementation supports some boot device, both SeaBIOS and some tianocore could boot it. If it doesn't support, then they both can't boot it. SeaBIOS, like yabits/tianocore, doesn't initialize any hardware - they are inheriting the initialized hardware from coreboot

Does it support TPM 2.0?

I've seen TPM 2.0 support at SeaBIOS source code, but I can't use it personally because my device doesn't support it. So this answer is similar to above: if your device has TPM 2.0 slot with a module installed to it, and your coreboot supports it, then your SeaBIOS (like tianocore) supports it too. If your device doesn't have TPM or your coreboot doesn't support it, then both SeaBIOS and tianocore can't use it

Network booting over TLS?

That could be achieved with the help of iPXE payload.

Trusted chains? Signed boot loader? Signed kernel? Verified boot? Trusted boot?

Check out "vboot" source code directory and also "heads" project, to realize that your coreboot+SeaBIOS combination could be made secure if you would like

Seriously, there is nothing tianocore can do that SeaBIOS couldn't ; that is why SeaBIOS is the default coreboot payload, and hopefully will remain so because we don't really need any uefi bloat in our devices; also, thanks to UEFI extensible nature by design its relatively easy to extend it with some malicious module, and if almost everyone including you is running that vulnerable-by-design bloat, that doesn't add much to your security :P

[michaelb1]

As opposed to what? blindly executing the first 440 bytes of a given hard disk, and expect it to not be malware or chain to malware? BIOS is not good enough. Being chained to a reverse engineered proprietary technology from 30 years ago made into a standard is not "good enough".

Check out "vboot" source code directory and also "heads" project, to realize that your coreboot+SeaBIOS combination could be made secure if you would like

[michaelb1]

Why not use SeaBIOS to boot to your favorite Linux?

Because Coreboot can't be ported on modern boards if you don't pay a ton of cash and sign an NDA, for starters.

And why we - as the open source enthusiasts - should care about what crap the bloated proprietary UEFIs are using to boot the things? Only the coreboot-supported boards should be our interest, and there are modern boards: check out Purism Librem and Librebox, for example. And, actually even those proprietary UEFIs could use SeaBIOS as a module, so my answer is still valid even for this proprietary crap.