Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LinuxBoot: Linux as Firmware

linuxboot.org

Post reply on HN
Print view View original

41–50 of 187 posts

Re: LinuxBoot: Linux as Firmware

#41

Post by AdmiralAsshat »

mikepurvis wrote: post #5
Palomides wrote: post #2

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?

Similar philosophy to Petitboot, for which the rationale is given here: https://www.youtube.com/watch?v=CQueOHKO58M Obviously it's a heavy weight solution, but the idea of having more drivers and better support is compelling— it's a much easier path to exotic boot setups, eg over wifi, off a SAN, whatever.

> Obviously it's a heavy weight solution, but the idea of having more drivers and better support is compelling— it's a much easier path to exotic boot setups, eg over wifi, off a SAN, whatever.

So...this is strictly my own personal experience, but, I've always had better compatibility with my hardware in the BIOS than I have had in any OS. I can't count the number of times my K/V/M has worked in the BIOS, then suddenly stopped working once DOS/Windows/Linux started booting.

Re: LinuxBoot: Linux as Firmware

#42

Post by [deleted] »

aplorbust wrote: post #36

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 becaus…

[deleted]

Re: LinuxBoot: Linux as Firmware

#43

Post by anderspitman »

alerighi wrote: post #35
hollander wrote: post #19

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

I think it's because the first Linux image has to be written in the firmware ROM, so this make upgrades difficult because you have to flash a new firmware on every kernel update. So it's more practical to have a stripped down Linux kernel that loads a complete kernel from disk.

But if the primary purpose of updating your kernel is security updates (which is the case for some people), shouldn't you be making the effort to do all that flashing? (honest question) I realize the attack surface would be much smaller since you'd be running a lot less services.

Re: LinuxBoot: Linux as Firmware

#44

Post by vanderZwan »

euyyn wrote: post #4
Palomides wrote: post #2

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?

Check Ron Minnich's talk explaining the why: https://schd.ws/hosted_files/osseu17/84/Replace%20UEFI%20wit... (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.

> DigitalTermometerSensor (sic)

Heh, that gave me a chuckle

> Userland written in Go (http://u-root.tk)

So much for Go not being a systems programming language.

Re: LinuxBoot: Linux as Firmware

#45

Post by guipsp »

tadfisher wrote: post #30
faragon wrote: post #23

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 :-)

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 s…

(formely known as gummiboot)

Re: LinuxBoot: Linux as Firmware

#46

Post by aidenn0 »

hugelgupf wrote: post #40
icc97 wrote: post #39

> 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.

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

Out of curiousity, what devices do you have that it takes 8 minutes for the DXE to initialize?

Re: LinuxBoot: Linux as Firmware

#47

Post by hugelgupf »

anderspitman wrote: post #43
alerighi wrote: post #35

Earlier quoted context omitted.

I think it's because the first Linux image has to be written in the firmware ROM, so this make upgrades difficult because you have to flash a new firmware on every kernel update. So it's more practical to have a stripped down Linux kernel that loads a complete kernel from disk.

But if the primary purpose of updating your kernel is security updates (which is the case for some people), shouldn't you be making the effort to do all that flashing? (honest question) I realize the attack surface would be much smaller since you'd be running a lot less services.

Yes, there should be firmware updates for the kernel in flash. (And we haven't really figured out how to handle that yet.)

But such firmware updates likely have different constraints and a different schedule than your kernel-in-production updates. People will likely have much different requirements for the kernel in flash than for the kernel in production. It may be that for your use case and threat model, they'd be the same - but that's up to you to figure out and decide.

Re: LinuxBoot: Linux as Firmware

#50

Post by BenjiWiebe »

hugelgupf wrote: post #13
throwaway2048 wrote: post #7

Earlier quoted context omitted.

why boot linux then boot linux again, rather than just booting linux once?

Chances are you don't want to re-flash your firmware on your servers just to change what kernel you run in production. The kernel in flash also has space constraints that will make it a pretty small kernel with a lot of features turned off.

In fact, you'd have to reflash to update Firefox! Oh wait, Firefox won't even fit on the ROM chip. No wonder we don't use the ROM chip as our main storage...
Post reply on HN