Linux Foundation Announces "LinuxBoot" To Replace Some Firmware With Linux Code

[starshipeleven]

Mostly clear, though I have a problem with the sentence . It sounds odd. I think it lacks comma or something… Does it try to underline that Coreboot have to call FSP, or what?

Yes, FSP is required in Coreboot and it does most of the job on its own too. I've seen Coreboot devs in the mailing list say to other devs (with an NDA with Intel) that they could just use FSP and then use that to pull up an uboot and skip using Coreboot alltogether.

Similar thing with AGESA (AMD), Coreboot has to use it to bringup stuff in AMD land, but I don't know how actually self-sustained it is. Probably less than FSP.

[starshipeleven]

- LinuxBoot simply reuses the CoreBoot initialisation parts (basically, the parts that call into the manufacturer's Firmware Support Package) and use them to boot straigh a kernel. It's basically some parts of CoreBoot configured to work in the same way as it was envisioned back in the LinuxBIOS era.

No. The low-level initialization is mostly done by blobs also in Coreboot anyway, so they skip Coreboot and just take stock firmware, open it up with UEFI tools, remove crap and change configurations to get the UEFI core system boot a Linux kernel instead of pulling up what would be UEFI userspace (the bootloader and most UEFI features).

The graphics on their site https://www.linuxboot.org/ show that they can use a similar approach on UEFI OR on Coreboot OR on uboot based systems.


If you see the few posts in their "mailing list" https://groups.google.com/forum/#!forum/linuxboot you see they did what I said. Hacked stock UEFI to get to the core and launch a Linux kernel instead of UEFI services once the system was initialized enough.

[polarathene]

Regarding Coreboot, According to docs :

The best comparison would be LinuxBIOS, CoreBoot's ancestror.
- LinuxBoot and LinuxBIOS share the same basic idea : have the firmware initialise the bare minimum hardware (CPU, RAM, etc.) and then use a Linux kernel to initialize the rest (disk drivers, network drivers, etc.)
- Since the LinuxBIOS era, CoreBoot has evolved : it can handle hardware initialisation, and boot several other payloads (launch GRUB, run a full blown UEFI firmware, etc.)
- LinuxBoot simply reuses the CoreBoot initialisation parts (basically, the parts that call into the manufacturer's Firmware Support Package) and use them to boot straigh a kernel. It's basically some parts of CoreBoot configured to work in the same way as it was envisioned back in the LinuxBIOS era.

(So LinuxBoot is basically CoreBoot, but without any initialisation that would be redundant to a Linux kernel and with "boot a linux kernel+initrd" the only payload - LinuxBoot is CoreBoot in it's old-school LinuxBIOS variation).

It's not exactly FSF "freesoftware"-compliant. It's not "libreboot", it actually DOES rely on the manufacturer's blob, but keep the blob limited (only initialising stuff that the Linux kernel cannot, like RAM, etc.) with the hopes that the needed part are so small, that they can be disassembled and reverse generated. Basically, their approach to free-software's freedom to tinker is not LibreBoot's "No BLOB firmware" policy, but instead a big "fuck you, we'll throw a debugger at it and exercise our freedom to tinker anyway, no matter what you think" to the manufacturer.

I personally doubt how much with could actually work in jurisdiction such as the US: Do you have protections/exemptions from DMCA & co when doing security research ?

Ok, so LinuxBoot is more of a subset of CoreBoot, where it's ok to have blobs for other parts but whenever possible it's open-source and uses the Linux kernel earlier than without either of these?

It still allows you to boot into Linux supported FS instead of just FAT32 boot for UEFI bootloader? Does it go straight into linux or can you still use GRUB2/systemd-boot/refind?(or are these specific to CoreBoot only?)

Are the listed advantages(beyond better compatability), like the ones mentioned in the article also applying to CoreBoot?(as in prefer CoreBoot over LinuxBoot where supported?) Someone mentioned here I think that it can alternatively be used as a payload for Coreboot(where I guess it replaces that functionlity that it shares similarity with?)

With LinuxBoot is likely to get around the mentioned CoreBoot support issue for motherboards beyond Sandy/Ivy bridge CPUs? I'm not sure how likely we're to see motherboard support for consumers, still sounds like it will require quite a bit of time/effort and hardware access to the devs involved?

Does CoreBoot or LinuxBoot replace the UEFI settings motherboards provide at boot at all? Or is that just a separate UEFI rom that when it updates firmware won't cause any conflicts?

[starshipeleven]

Ok, so LinuxBoot is more of a subset of CoreBoot,

More like a brainchild, the same concept of Coreboot, but adapted to modern times, as things changed since Coreboot came out.

Coreboot was created to replace the low-level initialization phase of the BIOS with opensource software. Then it could launch payloads to emulate BIOS services (Seabios), eventually also UEFI services (Tianocore), or uboot (a popular embedded system bootloader) or GRUB or just boot a Linux system raw from flash as a payload.

Since in the last decade Intel/AMD have replaced large part of the low-level initialization with a blob (as they can't just opensource it anymore, for their own reasons), Coreboot in anything remotely modern is mostly a wrapper for the FSP (intel low-level blob) and ME or AGESA + PSP (for AMD), the Coreboot project as originally envisioned is pretty much dead.
As said above, Coreboot devs already said you could skip Coreboot and just use FSP + ME to boot a payload like uboot, which then could boot whatever (as it can also emulate UEFI services itself). Of course the documentation to do so is under NDA, as are blobs to do that, so you opensource fan can't do it, period.

LinuxBoot project acknowledges that low-level initialization phase is now off-limits, so it shifts its focus from replacing these blobs (not possible) to secure the board firmware by replacing UEFI, so any of the (many) UEFI vulnerabilities won't affect the system anymore. The other main developer of Linuxboot discusses this in the talk he gave about Heads firmware, which is LinuxBoot using Coreboot as a base firmware https://trmm.net/Heads_33c3#Why_firm...s_so_important

LinuxBoot is basically a payload, but it is meant to be deployed by the core UEFI blob from the stock firmware. Also Coreboot can deploy it, but that does not have much future on x86 as said above.

The UEFI core blob in this case is doing what Coreboot would do (low-level initialization) which is now done by a blob anyway even in Coreboot.
But to the contrary of Coreboot, the UEFI core is 100% working fine already and does not require reverse-engineering or NDAs or anything because it comes from stock firmware (which is working already).

See the fourth and fifth images here https://trmm.net/LinuxBoot_34c3 (slides in the presentation) that show a before (UEFI) and after (UEFI core + LinuxBoot).

Currently there are two projects using LinuxBoot payload, either Heads (which is LinuxBoot + Coreboot) linked above, or NERF, which is using UEFI core blobs + LinuxBoot. https://www.phoronix.com/scan.php?pa...ERF-UEFI-Linux

Both developers are cooperating and can be found in the LinuxBoot mailing list. Currently there isn't much else than these two as the project is very young. The NERF developer is Ron Minnich, the founder of Coreboot and now a Google employee.

where it's ok to have blobs for other parts but whenever possible it's open-source and uses the Linux kernel earlier than without either of these?

Coreboot is OK with using blobs, you are confusing it with Libreboot or whatever, that is the de-blobbed (and crippled) version.

It still allows you to boot into Linux supported FS instead of just FAT32 boot for UEFI bootloader?

Yeah that's the point of getting a Linux kernel in there. Technically speaking, it can do whatever you want. It's a linux kernel stored on a flash chip with more than 8 MB free (after trimming the UEFI userspace modules you free up so much space...). You can compile in any driver or functionality you want, and it will fit in there.

To make a comparison, OpenWrt/LEDE fits a full wifi router operating system with web interface in a 4MB flash chip (no USB/sata or storage drivers), and a full-feature firmware (with drivers and tools for storage devices) will fit in 8MB.

It's common to find motherboards that have 32MB, 64MB or even 128MB of onboard flash for their firmware. That's a ton of space for an embedded Linux firmware. I mean I can fit even OpenSUSE's vmlinux+Initrd (the kernel and initial userspace bootstrapper), which are 10 MB and 15 MB respectively.

Does it go straight into linux or can you still use GRUB2/systemd-boot/refind? (or are these specific to CoreBoot only?)

Currently they are booting another linux kernel with Kexec functionality of Linux kernel https://linux.die.net/man/8/kexec , and are only exposing ACPI tables/API to it (so the kernel you are booting knows what hardware is available and can do ACPI stuff like buttons and leds and power management)

So in its current form there is no need for bootloaders like GRUB2, nor boot managers like rEFInd and systemd-boot, as the linux kernel is able to act as a bootloader too. I don't think it is configurable at this point, but it is early development stage and making it configurable isn't terribly hard, given what it is.

The above is fine something for a Linux system, while for a Windows system it's probably not fine at all.

I don't know how easy it would be to throw around some UEFI emulation in the linux kernel to keep Windows happy and booting fine too.
I also don't think this is a huge priority on their checklist, since they are working on servers that will never see Windows.
Also Windows would nullify the point of using a safer board firmware anyway.

Are the listed advantages(beyond better compatability), like the ones mentioned in the article also applying to CoreBoot?(as in prefer CoreBoot over LinuxBoot where supported?)

No, because LinuxBoot is technically a payload, so not the same thing.

LinuxBoot does not (and cannot) do the low-level initialization phase. Coreboot (+blobs) does, UEFI core does, uboot (+ embedded BootROM) does.
Then they call up a payload.

With LinuxBoot is likely to get around the mentioned CoreBoot support issue for motherboards beyond Sandy/Ivy bridge CPUs?

Yes, because as said above they don't need anymore all the info and NDA and whatever to be able to get the low-level initialization phase working, they just take stock firmware, use UEFI tools to trim it down to what actually does the initialization, add the LinuxBoot payload, and then flash it back.

They only need to workaround any bugs or differences in stock UEFI core to boot their Linux payload directly, as stock UEFI firmwares are not all the same, and even while they should follow a standard on internal interfaces and structure, they don't 100% adhere to it.

I'm not sure how likely we're to see motherboard support for consumers, still sounds like it will require quite a bit of time/effort and hardware access to the devs involved?

Yes, but it is massively reduced if compared to Coreboot support, as the harder part (no documentation without NDA and paywall) is taken as-is from the stock firmware, and is 100% working already.

The job of someone that wanted to add support in LinuxBoot is just get the core UEFI to boot the Linuxboot payload instead of UEFI userspace.

The difficulty in doing that is more like making a custom Android firmware for a device or doing BIOS modding. Coreboot requires much more skills and information, which is why it mostly stagnated apart from Google's involvement.

Does CoreBoot or LinuxBoot replace the UEFI settings motherboards provide at boot at all?

The "UEFI settings" is a native UEFI application included in the stock UEFI firmware. If you install Coreboot it is erased just like the rest of the UEFI firmware. It is also erased or not used if you use LinuxBoot, because it replaces all UEFI services with a linux kernel + small embedded-like userspace, and bare ACPI tables/API exposed.

Coreboot per-se has no such thing, and both SeaBIOS (the BIOS payload) or Tianocore (UEFI payload) for Coreboot has a crappy text-only interface for boot drive selection https://www.coreboot.org/TianoCore

Afaik, any hardware settings for Coreboot firmwares are defined at compile time. See here for a simple tutorial https://johnlewis.ie/compiling-your-...50-chromebook/ (note how he says "Check Enable VMX for virtualization", when in the make menuconfig selection screen, that's the compile option to enable VT-x for virtual machines)
This is an image of his chromebook boot selection screen https://johnlewis.ie/wp-content/uplo...726_165740.jpg

For LinuxBoot so far they just compiled/configured in the firmware image any hardware settings they wanted, so I guess they will follow the same general trend. I mean in most cases you don't really need to go and change UEFI settings (apart from boot configuration) more than once or twice.

Or is that just a separate UEFI rom that when it updates firmware won't cause any conflicts?

Both Coreboot and LinuxBoot fully replace the board firmware. You cannot update stock firmware as there is no stock firmware anymore. You can update Coreboot or Linuxboot.

LinuxBoot does use a core UEFI blob, but that is used only for low-level initialization, it does not have any kind of ability to communicate with the outside world, any UEFI API for the operating system are dead since the UEFI userspace was removed, so any exploit found in the stock firmware UEFI would not affect LinuxBoot firmware.

Any microcode can be safely updated in the LinuxBoot firmware regardless of what the stock firmware does, while for ME firmware you will probably have to take stock firmware images, uncompress them and then extract the ME blobs to integrate in the LinuxBoot firmware. They plan to automate most of the firmware creation process from stock firmware image.

If you use also ME_cleaner script to neuter or disable the ME, you can not care of ME updates/vulnerabilities, as it is now inaccessible (and with UEFI API also dead it will be pretty hard for malware to try to get in touch with it).

[starshipeleven]

ah come on, stupid forum software stop harassing me. Blocked post above for polarathene , it will appear in a bit when Michael unlocks it.

[DrYak]

polarathene : to complement the (excellent) comments of starshipeleven :

Keep in mind that LinuxBoot is currently aimed for single purpose hardware :
- a firmware to get Chromebooks boot straight to ChromeOS
- a firmware to get servers/cluster nodes up as fast as possible

The typical usage scenario in these case is custom building a LinuxBios that you taylor to get it chaining to the next task (an actual running ChromeBook / Server / cluster node).
So you probably won't be seeing it a lot on motherboard sold by constructor (well, except the few motherboard manufacturers that specifically target people building servers / cluster nodes).
And you'll definitely not see a "UEFI Settings"-style configuration payload, because the intent isn't to configure a lot of thing after that at the users discretion. It's more to design a base custom stuff to get Linux running ASAP.

[cj.wijtmans]

No. The low-level initialization is mostly done by blobs also in Coreboot anyway, so they skip Coreboot and just take stock firmware, open it up with UEFI tools, remove crap and change configurations to get the UEFI core system boot a Linux kernel instead of pulling up what would be UEFI userspace (the bootloader and most UEFI features).

The graphics on their site https://www.linuxboot.org/ show that they can use a similar approach on UEFI OR on Coreboot OR on uboot based systems.


If you see the few posts in their "mailing list" https://groups.google.com/forum/#!forum/linuxboot you see they did what I said. Hacked stock UEFI to get to the core and launch a Linux kernel instead of UEFI services once the system was initialized enough.

yuck initramfs.

[starshipeleven]

yuck initramfs.

what?

[cj.wijtmans]

what?

none of my custom linux installs have initramfs(which is all of them).
> wants to increase booting time]
> uses initramfs

[starshipeleven]

none of my custom linux installs have initramfs(which is all of them).
> wants to increase booting time]
> uses initramfs

With stock firmware their server needs like a minute and a half to complete boot (most of the time is spent in firmware stage, UEFI). They don't really care about a few seconds more or less when UEFI on servers sucks so hard on its own. The main goal currently is to replace the firmware successfully, optimizations can come later.

That said, can a kernel without an initramfs kexec another kernel? Does it not need the kexec tool at the very least? I'm sure it can be patched to do whatever, but as-is?