Live data from Hacker News

LinuxBoot: Linux as Firmware

linuxboot.org

51–60 of 187 posts

Re: LinuxBoot: Linux as Firmware

#51

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

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?

Re: LinuxBoot: Linux as Firmware

#52
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. :)

Re: LinuxBoot: Linux as Firmware

#54

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…

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.

Re: LinuxBoot: Linux as Firmware

#55
post #27
post #21

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

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.

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

Re: LinuxBoot: Linux as Firmware

#56
post #4

Earlier quoted context omitted.

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.

Its kind if weird, they compile at runtime as Go is a bit bloated. But userspace is a good fit for Go. GC timing is not an issue, it has good libraries. Much better choice than C for almost all userspace bringup.

Re: LinuxBoot: Linux as Firmware

#57

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…

A big one is GPU passthrough. Before graphics cards supported UEFI the old VGA BIOS was a nightmare to get working with virtualization. Now with a tiny bit of configuration you can get consumer GPUs to work just fine in virtual machines.

Re: LinuxBoot: Linux as Firmware

#58

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…

This is in the hands of the firmware/hardware manufacturers. AFAIK, for instance, the version of Minix that serves as Intel's ME will continue to be operational even if the UEFI is replaced by Linux. The issue is that 'firmware' actually means many different blobs of software in various ROMs spread throughout the system, from disk controllers to GPUs to memory controllers to NIC and so on. You will never be able to v…

That's why it is important to not buy random shiny devices. Open source hardware like for example the Teres-1 [0] are what allows us to stay in control. I can't wait for even more open successors based on RISC-V processors.

[0] https://www.olimex.com/Products/DIY-Laptop/

Re: LinuxBoot: Linux as Firmware

#59
post #27

Earlier quoted context omitted.

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.

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

You could try this: https://github.com/tianocore/tianocore.github.io/wiki/UEFI-E...

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

Re: LinuxBoot: Linux as Firmware

#60

Earlier quoted context omitted.

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

Its kind if weird, they compile at runtime as Go is a bit bloated. But userspace is a good fit for Go. GC timing is not an issue, it has good libraries. Much better choice than C for almost all userspace bringup.

We also have a mode that rewrites all commands' sources given so it can be compiled into one binary. It ahem needs some improvements, though :)
Post reply on HN