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

[polarathene]

https://xkcd.com/927/

The Linux Foundation and a lot of other opensource projects most of the time are just trying to circumvent closed source or problems coming from lack of documentation.
Like the intel "P-state". Coreboot is struggling to bring its ideas to modern motherboards/chipsets. With little luck, as most of them don't have enough documentation.

The other problem is resource fragmentation: too many projects on similar objectives lead to human and economic resources to be fragmented.

I know the prupose of coreboot. So this is just an alternative? No real worthwhile differences?

[AJenbo]

How does this compare to coreboot? Is there any advantage/disadvantage?

It uses CoreBoot for the hardware bring up, so this is just a payload for CoreBoot basically.

[DrYak]

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 ?

[Hi-Angel]

I know the prupose of coreboot. So this is just an alternative? No real worthwhile differences?

The issue is that CPU vendors are not documenting the memory controllers and CPU interconnects sufficiently for free versions of the initialization routines to be written.

Instead the vendors are provided binary blobs called the Firmware Support Package, the FSP. This opaque executable handles much of the early phase of the boot process and is an irreplacable part of the firmware, much like the microcode updates that are also opaque and non-free.

Even on coreboot systems with modern CPUs call into the FSP to do early chipset initiailization and on these SOC machines the FSP has grown in scope to include video setup and other parts that on these platforms it is even larger than SEC and PEI. So reusing SEC and PEI isn't quite as much of a moral compromise as it might seem at first, and on many platforms we can substitute our own PeiCore.pe32 to ensure that measurements would detect any unauthorized changes to that part of the ROM.

[SNIP]

We also have the configurability of Linux. UEFI supports booting from FAT filesystems. LinuxBoot supports whatever Linux supports, including fully encrypted disks if that is what you need. UEFI typically supports the one network card on a server's motherboard. LinuxBoot supports any network card that Linux supports. UEFI is limited to fetching the kernel via PXE and insecure protocols like tftp. LinuxBoot lets you use real network protocols as well as remote attestation. And the device drivers included can be stripped down to the ones that are actually required to boot in order to reduce unnecessary attack surface as well.

Source: https://trmm.net/LinuxBoot_34c3#Why_not_coreboot.3F

Mostly clear, though I have a problem with the sentence

Even on coreboot systems with modern CPUs call into the FSP to do early chipset initiailization and on these SOC machines the FSP has grown in scope to include video setup and other parts that on these platforms it is even larger than SEC and PEI.

. It sounds odd. I think it lacks comma or something… Does it try to underline that Coreboot have to call FSP, or what?

[DrYak]

That's how I've understood it too :
A non-LibreBoot, CoreBoot firmware, will definitely need to call into a blob given by the manufacturer in order to initialize the base hardware.

Also, according to the other presentation, they can also use u-Boot, or bits of sawed-off UEFI to do the same critical-base initialisation before jumping straight to Linux.

(So, still doing what was the goal back in the LinuxBIOS era, but building of completely different building blocks than coreboot)

But again, those building blocks aren't relevant as much as the blobs that we're currently forced to rely on.

[starshipeleven]

This looks a lot like an admission that the original coreboot ideal of replacing the entire boot stack from bootblock to payload is no longer possible on x86 systems (ME/PSP/Boot Guard), and that a more pragmatic solution is required that keeps the vendor in control. This does not bode well for coreboot IMO.

Intel has locked down all info (and many blobs) and only those with an NDA get it. It's completely impossible to port anything newer than Sandy/Ivy bridge to Coreboot (and even Sandy/Ivy was possible only because there was an info leak years ago) without signing up an NDA.

Although It's not about the "vendor", it's about the end user. Which in this case is mostly Google or other companies using the servers.

[starshipeleven]

How does this compare to coreboot? Is there any advantage/disadvantage?

Significantly easier to port on modern boards, as it basically just takes stock firmware and trims it down, exploiting the fact that UEFI is modular and has standardized internal interfaces.

UEFI has a "core" part that actually does low-level hardware initialization and a "userspace" that contains the bootloader and other features, like initialization of secondary stuff.

LinuxBoot replaces the UEFI userspace to boot a linux kernel instead of the original UEFI userspace, which then acts as "bootloader" and "secondary hardware initialization" part if needed.

[starshipeleven]

google will be involved with our non android devices from startup , horray !!! ......

As long as it is opensourced (and it is), there is no issue here.

Also note that the lead dev of LinuxBoot is still Ron Minnich, which is the founder of Coreboot project.

[starshipeleven]

http://static.davidedmundson.co.uk/b...ards_final.png

:-)

This is not a new standard, it uses UEFI internal API (between modules) to replace a large part of the original firmware with a Linux-based system that acts as setup and bootloader.

[starshipeleven]

It uses CoreBoot for the hardware bring up, so this is just a payload for CoreBoot basically.

Wrong. LinuxBoot is supposed to be loaded by the core UEFI blobs and replace bulk of UEFI userspace. It can be loaded by whatever else can boot a Linux kernel directly too (because no duh), of course.