
LinuxBoot: Linux as Firmware - doener
https://www.linuxboot.org/
======
aplorbust
IMO, the problems that [U]EFI introduces (that far exceed the historical
limitations it overcomes) should be _self-evident_.

IMO, he should not have to argue against having multiple, redundant copies of
drivers, shells and utilties each accessible only in its own "OS" (UEFI, GRUB,
OS). It should not be a debate. This is definitely not "defense in depth".
IMO, whomever controls the first OS controls the computer because there is no
need for the second and third OS in order to do work (make network
connections, move files across the network, etc.).

These "hardware features", whether its [U]EFI or ME _or whatever acronym_ ,
IMO is a land grab by hardware vendors over what we know as the "OS". Less
computer owner control, more vendor control. The sum effect of all these
"features" is that verification that something is the way that the owner wants
it and has not been modified is far too complex and is ultimately under
control of the vendor, not the computer owner.

I do most work on the commandline in text-mode (no graphics layer) and as such
_I only need one OS_ , with some basic utilities. When the news came that new
computers would have [U]EFI, I considered whether I should just switch from
the OS I am using to [U]EFI. It seemed to have all the utilities I would need
to do work, along with the ability to extend with new programs.

I only need one OS to boot to a working environment. I should be able to
choose that OS. I hope that Minnich and Hudson and others will consider that
the user may want to _choose_ a kernel other than Linux as a source for
drivers, e.g., BSD, Plan9, others incl. future OS not yet written, etc., even
if it today it has inferior driver support compared to Linux, or Intels UEFI,
or whatever.

The speaker seemed a bit perplexed when someone in the audience questioned
whether Linux is a "TCB". What is and what is not a "TCB" should be the
_computer owners_ decision, and not anyone elses. If the computer owner wants
to cede authority for that decision to a third party, then she can make that
_choice_. But IMO it should be a _choice_ made by the computer owner, and not
anyone else.

~~~
johncolanduoni
> These "hardware features", whether its [U]EFI or ME or whatever acronym, IMO
> is a land grab by hardware vendors over what we know as the "OS". Less
> computer owner control, more vendor control.

What control did you have with an old PC BIOS that you now are missing with
UEFI? Things like SMM and Intel ME that keep running after your actual OS has
started existed and were pretty much ubiquitous before UEFI became common in
consumer hardware. They aren't required to implement UEFI, and UEFI doesn't
enable them any more than PC BIOS did.

> I only need one OS to boot to a working environment. I should be able to
> choose that OS.

You weren't able to choose your PC BIOS any more than you can choose your UEFI
implementation now. There are PC BIOS and UEFI motherboards that can accept
coreboot or something similar, and in all other cases you're stuck with an
opaque vendor blob. At least with UEFI you have an opportunity to write your
own software that can be part of the boot process, doing so with a BIOS was
usually impossible unless you could install an option ROM.

> I do most work on the commandline in text-mode (no graphics layer) and as
> such I only need one OS, with some basic utilities. When the news came that
> new computers would have [U]EFI, I considered whether I should just switch
> from the OS I am using to [U]EFI. It seemed to have all the utilities I
> would need to do work, along with the ability to extend with new programs.

That's great for you but a lot of people want to be able to install different
OSes on their hardware. Having to duplicate the hardware initialization code
for each would be a major pain and would probably result in a lot of hardware
only supporting one OS (e.g. many consumer motherboards would probably be
Windows only in this situation). I really don't see how having the firmware
wedded to a particular OS is going to give people more choice.

~~~
chriswarbo
> What control did you have with an old PC BIOS that you now are missing with
> UEFI?

I had a PC with a BIOS once. It didn't seem as slick as the Kickstart I'd used
for the previous decase on my Amigas. It was also much less
configurable/programmable than the OpenFirmware that came on my subsequent PC.
My current machine uses libreboot, which is fine but I much prefer
OpenFirmware.

tl;dr "BIOS vs EFI" is a false dichotomy, and "it's better than BIOS" is
pretty weak praise for a boot system.

~~~
johncolanduoni
The person I was responding to was claiming UEFI was restricting their choices
and had "introduced" problems. I don't really see what OpenFirmware,
libreboot, etc. has to do with this. I didn't say UEFI was the best boot
system ever envisioned (I definitely think they could have done better) but
claiming it's some anti-consumer conspiracy in a way PC BIOS wasn't makes no
sense.

~~~
chriswarbo
For what it's worth, I agree with the parent. IMO Microsoft's strong-arming
around "SecureBoot" is enough to distrust everything to do with EFI.

------
BenjiWiebe
BTW, on the flip side of the UEFI haters, i.e. things that I can do with UEFI
more easily than BIOS (or at all).

I can now have a normal partition to put my boot loaders in rather than a
hidden chunk at the beginning of the disk.

I can easily update, add and remove boot entries from the OS command line.

I can forgo bootloaders entirely and use Linux as UEFI application.

I can use GPT and finally partition as much as I want.

I might have forgotten something too. :)

~~~
gnufied
On other hand - a common partition that is shared among all operating systems
has too high chance of getting corrupted or simply blown away by another
install.

Just yesterday - RHEL7.5 beta install overwrote UEFI entry of Ubuntu for me
and Ubuntu became unbootable. On another laptop - Fedora blew away my Windows
bootloader from UEFI partition and I have been too lazy to recover it.

Also - because UEFI partition actually contains things needed for booting
these operating systems - it is almost always non-trivial to restore.

~~~
johncolanduoni
You can have multiple EFI system partitions on the same disk. The Windows
installer does not like this, but it won't affect the actual boot process
after it's installed. The Linux distros I've seen don't mind at all, since
/boot/efi is usually mounted by UUID in your fstab.

~~~
ComputerGuru
No you really can't. There can only be one ESP and that's in the spec. You can
have multiple partitions each assigned as /boot for a different OS, but there
can only be one ESP which is used by the firmware to store its settings, etc.

The EFI spec [0] is _officially_ silent about the presence of multiple EFI
system partitions __on non-removable hard drives __, but explicitly forbids
multiple ESPs on removable disks, per §11.2.1.3:

> For removable media devices there must be only one EFI system partition, and
> that partition must contain an EFI defined directory in the root directory

But in practice, Bad Things (TM) happen if you have more than one ESP on the
boot disk.

An ESP isn't just a partition mounted to /boot or one that has bootfiles or a
bootloader, it's (in practice) a FAT32 partition that has a different
filesystem ID, in particular, the magic GUID
{C12A7328-F81F-11d2-BA4B-00A0C93EC93B}

I'm the author of EasyBCD and numerous other boot utilities and spent a hell
of a lot of a time (too much time) researching and working around the various
UEFI deficiencies in various desktops, laptops, firmware implementations,
bootloaders, and operating systems.

Here's a Microsoft bulletin on the matter: [https://support.microsoft.com/en-
us/help/2879602/unable-to-b...](https://support.microsoft.com/en-
us/help/2879602/unable-to-boot-if-more-than-one-efi-system-partition-is-
present)

(long story short, the Windows kernel may bork if it runs into multiple ESPs
and fail to load. Our bootable boot repair CDs wouldn't boot into the WinPE
kernel because the disk management subsystem would hit an infinite loop in
certain cases (not this case). We ended up switching to FreeBSD for our live
CDs and writing our own disk repair subroutines to get around cases where even
Windows live CDs wouldn't boot so we could fix the customer's PCs)

Linux may not hang if there are multiple ESPs (except it sometimes does), but
it certainly doesn't support treating multiple partitions as the ESP
simultaneously, either: [https://superuser.com/questions/688617/how-many-efi-
system-p...](https://superuser.com/questions/688617/how-many-efi-system-
partitions-esp-can-a-computer-have)

[0]: [https://www.intel.com/content/dam/doc/product-
specification/...](https://www.intel.com/content/dam/doc/product-
specification/efi-v1-10-specification.pdf)

~~~
danudey
> I'm the author of EasyBCD

Thank you!

Also, maybe you can answer this: what's the 'correct' way for systems to
handle multiple disks with an ESP partition each? In other words, if I'm using
software RAID and clone the partition tables, should I assume that the UEFI
firmware will default to the first disk's ESP, or is that set when boot
configurations are updated?

~~~
ComputerGuru
> Thank you!

No problem! Glad you found it useful.

> if I'm using software RAID and clone the partition tables, should I assume
> that the UEFI firmware will default to the first disk's ESP

With regards to your question: I guess it depends on what you mean by
"software" raid. Enabling RAID in the "BIOS" (that term has now come to
encompass the firmware configuration utility for UEFI motherboards as well)
(typically Intel "RST" rapid storage RAID, nvraid for nVidia chipsets (less
common these days), AMD raid, etc.) is 100% software raid, which does nothing
more than make the BIOS aware of its presence (and toggle a flag so that RAID
drivers can find the array) so that it doesn't run into exactly the problem
you describe, i.e. it'll be aware of the cloning at a level higher than the
UEFI bootloader init, which will only see the virtual raid volumes rather than
their independent components.

Now if you put all that aside and are just wondering how it selects in the
presence of multiple ESPs on different devices that made it through to the
bootloader layer: the UEFI "BIOS" doesn't know (and can't know) since UEFI has
done away with the concept of drive order entirely. You can set the order
manually in the "boot device order" section (typically on the boot tab in the
BIOS config) or choose the one-time boot target via F11 or F12 at the boot-up
screen, but otherwise it's just a tossup and the BIOS is free to chose any
local device's ESP as "the" ESP. In practice, it'll choose one of the SATA
drives (assuming a mix of other interfaces such as NVMe), either the first to
respond (not an issue with SSDs which respond quickly, but magnetic media
takes time to spin up if you're still using old HDDs) or the first to be
enumerated by the SATA controller (which has its _own_ firmware and its own
level of abstraction and logic (and bugs) and whatnot).

BUT in the case of software raid, that RAID 0 should actually extend to the
GPT itself and both drives will have the same content and mirrored ESPs, so in
practice it won't matter which is loaded (so long as your OS doesn't do
anything stupid like try to modify the on-disk structure before loading the
RAID-aware storage driver. I've seen BIOSes that "helpfully" store a copy of
the current firmware to a locally-attached disk with an understandable
partition format (so FAT32) that ended up breaking a RAID because the drives
were no longer in sync because the BIOS wasn't aware of the mirror).

------
ComputerGuru
There is virtually no information on that page. I don't understand why this is
getting voted so highly. I'm interested (this falls right in my area of
expertise, see my other comments on this page) and I've heard about this
proposal before, but the landing page this story links to is just a
placeholder with no useful (technical or marketing) information.

~~~
steeve
This is probably because people saw the LinuxCon video and are excited that
it's out.

At least that's my case :)

~~~
nickik
Do you have a link to the talk?

~~~
hugelgupf
The front page of LinuxBoot has links to talks' videos and slides.

------
snvzz
I do like the coreboot + lightweight payload (such as u-boot or grub)
approach, and simply can't see any benefit of jamming a Linux kernel in;
Simplicity is itself value.

Even if I were to find their approach appealing (I don't), Linux's monolithic
design with no driver APIs doesn't even seem like a good fit for this;
NetBSD's kernel size (and its cleaner design, and the RUMP kernels feature),
Minix3 (high assurance, unlike Linux) or even Genode are far better suited.

But, seriously, we need less, simpler, cleaner code, and this "jam Linux into
everything" approach seems nothing less than the old "when you have a hammer,
everything looks like a nail" problem.

~~~
zokula
> NetBSD's kernel size (and its cleaner design,

Don't make me laugh.

~~~
jchw
Most of us have not read the NetBSD kernel source code (I have not.) I've read
a small bit of the Linux source code. Please inform me of why I should laugh
at this claim.

------
hollander
If we use LinuxBoot to boot Linux (desktop or server), then why don't we boot
direct into Linux (desktop or server)?

~~~
e12e
There's probably an argument to be made for a lean bootloader/kernel that does
minimal work - and for a os kernel that's more general. But with network boot
(ethernet, WiFi stack, network stack, one or more network transports ((t)ftp,
nfs?..) and support for encryption... The line does blur.

Might be worth it to have minimal Linux "profile" that support "booting" other
Linux via kexec.

But then, will you boot nt, freedos, bsd and minix via kexec too?

~~~
kazinator
> _There 's probably an argument to be made for a lean bootloader/kernel that
> does minimal work - and for a os kernel that's more general._

We had that in Linux; it was called LILO (Linux loader), consisting of a 512
byte machine language program run from the boot sector which would load a
canned sequence of more sectors, a slightly larger program, which would then
load a kernel image from a sector map.

Before that, generations of machines going back to the dawn of computing had
minimal bootstrap sequences.

But, on the flipside, idea of more capable boot firmware precedes Linux by
probably ten years if not more, like on Sun workstations and whatnot.

------
Palomides
wait what? using a whole linux kernel as firmware before booting another OS to
improve speed, reliability, security? does this seem strange to anyone else?

~~~
euyyn
Check Ron Minnich's talk explaining the why:

[https://schd.ws/hosted_files/osseu17/84/Replace%20UEFI%20wit...](https://schd.ws/hosted_files/osseu17/84/Replace%20UEFI%20with%20Linux.pdf)

(The video of the presentation is linked in the OP).

There's already two and a half obscure OS's running underneath the OS for
booting. So this replaces all that crap with something lean and good.

~~~
mevile
Firmware with a built in web server is pretty spooky. Why do they have that?

~~~
y0ssar1an
Most UEFI implementations have a network stack these days. It's horrible.

~~~
Hello71
I agree, but it's not exactly like PXE didn't exist before EFI was invented,
and AIUI EFI actually decided to reuse PXE instead of NIHing another
overengineered non-solution, so honestly that's not even so bad.

------
b0rsuk
Correct me if I'm wrong, but you still need a coreboot-compatible motherboard
?

~~~
ganshun
Actually no. We've demonstrated this on boards without using coreboot support
such as OCP's Winterfell machine. The reason is that we're inserting the Linux
kernel in UEFI's DXE stage, whereas cpu init such as memory training are still
handled by UEFI's PEI stage. From the perspective of UEFI, the Linux kernel is
just another DXE to execute.

~~~
chris_wot
Is there a document that does a decent job of explaining how UEFI works?

~~~
ganshun
You could try this:
[https://github.com/tianocore/tianocore.github.io/wiki/UEFI-E...](https://github.com/tianocore/tianocore.github.io/wiki/UEFI-
EDKII-Learning-Dev)

I don't know of any easily digestible document though.

~~~
chris_wot
Thanks!

------
orionblastar
I remember my Commodore 64 days where you turned on the C64 and it booted
right into BASIC because it loaded BASIC from a ROM, or it loaded software
from a cartridge. The 1541 floppy drive was extra, or the tape or modem etc.

The thing I liked most about the C64 was booting into BASIC as soon as you
turned it on.

If Linux becomes the Firmware or installed on Firmware on an EEPROM or
whatever, it can boot into a LiveCD Distro of Linux from an EEPROM faster than
from a hard drive or USB drive or DVD whatever.

I have to say some computers are getting rid of DVD/CD/BluRay drives and
booting from USB Drives, which makes download a Linux Live CD/DVD and test it
out, now it can just boot from BIOS with the bare minimum LiveCD distro, and
allow you to have tools to work on hard drives and fix them etc.

If I ran Commodore, and brought it back from the dead, I'd make Intel/AMD PCs,
and I'd also make Commodore Bridge Cards that run a 68M/PPC Amiga on a
PCIe/PCI card that can run in the host OS as a Window or Full Screen and can
make virtual hard drives and floppies out of files, etc. Maybe a C64/C128/C65
on a card with ports from the Commodore series to hook up real 1541 drives
etc. The Commodore Colt PCs will have a VIC-20 series that is low end, and a
Mad Max series that is high end and built for video games and SteamOS or run
Windows. They will come with Debian Linux but can be reformatted for Windows
or SteamOS and make a deal with Steam to run C64 games in emulators the same
way Sega Genesis games are run in emulators.

I'd also try to make ARM-based PCs running Linux for under $100 based loosely
on the Raspberry PI but assembled. Contribute to the Raspian or whatever it
uses with an emulator app for 8-bit Commodores and they can buy ROMs from a
store in the emulators to download and run, after getting permission from the
software companies if they still exist to license them and pay 10% or whatever
the fee is to the customer.

~~~
RickSanchez2600
People have tried to reboot the Commodore IP only to make some Linux version
with all the emulators on it running on a PC in a keyboard case that resembles
a C64 or Amiga 500. I think yours being a box that has expansion slots would
do a lot better. They could not figure out how to monetize the ROMs as TOSEC
on Archive.org and other places has virtually every ROM, Tape, and Floppy ever
made for the C64.

I like that idea of selling C64 games on Steam the same way they sell Sega
Genesis games. Just port VICE to use Steam and verify codes for purchases for
different ROMs to load after being paid for.

------
jagger27
Is there any chance of a big player like Dell getting behind this project?
Will servers ever ship with this firmware?

~~~
hugelgupf
Horizon Computing will ship OCP nodes running LinuxBoot / NERF in Q2.

------
djsumdog
I don't understand what's wrong with Grub. UEFI loads Grub which loads your
OS. The previous "OS" gets replaced in each iteration (except for the Intel ME
stuff .. which is off running somewhere in its own little world).

Grub supports raid, lvm2 and luks. I literally have a 1 partition with LUKS
that contains an LVM with a swap and root (/) volume. Yes, that means I have
an encrypted boot. The only thing unencrypted is my EFI/SPI partition.

~~~
jchw
UEFI has more privileges than your OS, just like ME has more privileges than
UEFI. How do we know it hasn't messed with the environment in ways we can't
see? How do we know our UEFI firmware wasn't compromised? I'd argue it's very
hard to tell.

------
95014_refugee
Boot firmware by any other name is still boot firmware, and the same forces
that have made EFI what it is will affect any other thing you try to put in
its place.

------
icc97
> Typically makes boot 20 times faster

Really? That means my current Fedora boot on an T430 with SSD of 20s would go
down to 1s? Seems unbelievable.

~~~
hugelgupf
We should clarify that. Our example is an OCP Winterfell node, where boot time
went from 8 minutes to 20 seconds.

~~~
fmntf
That's an edge case. Asserting that boot is _typically_ 20 times faster is
misleading.

~~~
thudson
It's pretty typical boot time for most UEFI server platforms with network
cards and RAID controllers. The Dell R630 takes about six minutes, the HP
DL3x0 is about eight and the Lenovo x3550 takes over ten. Of the ones I've
tested only the Intel s2600wf is under two minutes in a stock configuration,
but with LinuxBoot it is less than twenty seconds to a Unix shell despite the
PEI and DXE serial debugging messages:
[https://www.youtube.com/watch?v=0HISDFXZvSI](https://www.youtube.com/watch?v=0HISDFXZvSI)

------
vectorEQ
if i look at the diagram it looks like linux replaces a bootloader? or is that
a bit too simple of a conclusion?

wouldn't a minimalistic bootloader loading linux then not do about the same?
(if you implement coreboot) since that leaves linux to configure everything
something like GRUB would usually initialise? I think linux actually re-
initialises most things that are done by the loader, and seeing that linux
kernel is in the 'memory init' zone, i'd say it's not 'in firmware' and so
wouldn't change much??

in my eyes, bios confiugres some stuff like smm etc., then hands over to
bootloader (grub or so) which further initialises system ,and hands over to
OS. (linux?) So this just seems to skip the bootloader? of which most
initialisation is ignored / reinitialised by linux anyway?

------
Ericson2314
MS-DOS on BIOS Linux on MS-DOS (UEFI) ??? on Linux (this)

Great

------
nickwinlund
Wonderful! I detest the UEFI/secure boot schema in use on post-Windows 8
systems

~~~
ComputerGuru
This doesn't really have anything to do with Windows, recent Linux and FreeBSD
release prefer to use UEFI and Secure Boot if available.

While UEFI is platform/OS-agnostic, it's too early to tell if this LinuxBoot
will be as open (even if better designed). Additionally, there _are_ benefits
that Secure Boot brings to the table (notable with regards to security and
integrity verification) that you should not be so hasty to throw out along
with the bathwater. If LinuxBoot does not support Secure Boot, I can guarantee
you it will be a project dead in the water, no one (in the corporate world)
will want to go back to untrusted boot.

~~~
thudson
The threat model that LinuxBoot is addressing is different form SecureBoot and
it can use the well known, normal Linux tools rather than the unconventional
UEFI ones.

The Heads runtime can do things like use TPMTOTP to attest to the user that
the firmware is unaltered and includes gnupg to verify the kernel and root
filesystem signatures with the user's own key.

For cloud systems a LinuxBoot runtime can use the TPM or other trusted
hardware to remotely attest to the client's own provisioning server that the
configuration is unchanged, and since it is reproducibly built, that the
firmware is what the user expects. This is significantly more trustworthy than
the binary blobs and non-reproducible UEFI firmware on most servers.

------
Annatar
No, and I’m sorry that it came to this. The article presumes that the quality
of the Linux kernel is indisputable, and it simply isn’t.

------
faragon
Now systemd will be in the boot loader, too, so finally we'll be able to have
_perfect_ power management in Linux, once it controls everything first-hand
:-)

~~~
tadfisher
You can put whatever in the initramfs, but since Linux just boots as a UEFI
executable with CONFIG_EFI_STUB=y, it would be somewhat silly to start up a
full userland via systemd in the bootloader.

systemd-boot is a thing though, which is a pretty small UEFI application that
reads a Freedesktop Boot Loader Specification config [1] from an EFI partition
and tells UEFI to boot a kernel directly. Definitely no Linux or systemd-init
involved though.

[1]:
[https://www.freedesktop.org/wiki/Specifications/BootLoaderSp...](https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/)

~~~
guipsp
(formely known as gummiboot)

