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

71–80 of 187 posts

Re: LinuxBoot: Linux as Firmware

#71

Post by Sephr »

johncolanduoni wrote: post #57
BenjiWiebe wrote: post #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…

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.

Maybe for AMD GPUs, but getting consumer Nvidia GPUs working with VT-d on Nvidia's drivers is a little difficult. GPU passthrough is not something Nvidia wants to support on consumer GPUs.

Edit: s/very/a little/

Re: LinuxBoot: Linux as Firmware

#72

Post by hugelgupf »

e12e wrote: post #51
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)?

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, fre…

Booting via kexec is the intended idea here. Theoretically, it should be possible to boot any other OS with kexec. We may have to test that assumption for this project...

Re: LinuxBoot: Linux as Firmware

#73

Post by andyjpb »

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.

Maybe. That kernel is only running for a short time before it is replaced by the main OS kernel.

In a lot of scenarios it won't connect to the network and therefore will be difficult to exploit. If it does connect to the network (for network boot) then the security profile is different (how do you authenticate the image it downloads) but it probably won't be running many services of its own that could be exploited.

To exploit it locally it would have to run user supplied commands and binaries and hopefully it would be possible to make it difficult to inject these in an adhoc way.

The kernel that your main OS runs does so for a much longer time and with many more processes and services. The security vulnerabilities are exploitable when these different processes run and interact and when these processes are doing things in different security domains.

The scope of what the main OS is doing is much larger and much less pre-determined and therefore easier to exploit.

Re: LinuxBoot: Linux as Firmware

#74

Post by lathiat »

Sephr wrote: post #71
johncolanduoni wrote: post #57

Earlier quoted context omitted.

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.

Maybe for AMD GPUs, but getting consumer Nvidia GPUs working with VT-d on Nvidia's drivers is a little difficult. GPU passthrough is not something Nvidia wants to support on consumer GPUs. Edit: s/very/a little/

It's "very difficult" because the drivers are intentionally nerfed not to load in a virtual environment. Your statement is entirely correct.

Re: LinuxBoot: Linux as Firmware

#75

Post by fmntf »

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.

That's an edge case. Asserting that boot is typically 20 times faster is misleading.

Re: LinuxBoot: Linux as Firmware

#76

Post by morganvachon »

madez wrote: post #58
Santosh83 wrote: post #38

Earlier quoted context omitted.

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/

I wonder why they are using the Allwinner A64 if they are concerned with FOSS though? It's one of the more serial offenders when it comes to GPL violations[1], and it has a backdoor in its custom kernel config that could be used to take over the system[2]. I'm not trying to crap on your efforts, it's just smart to vet any system even if they claim to be FOSS or open hardware friendly.

[1] http://linux-sunxi.org/GPL_Violations

[2] https://arstechnica.com/information-technology/2016/05/chine...

Re: LinuxBoot: Linux as Firmware

#77

Post by madez »

morganvachon wrote: post #76
madez wrote: post #58

Earlier quoted context omitted.

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/

I wonder why they are using the Allwinner A64 if they are concerned with FOSS though? It's one of the more serial offenders when it comes to GPL violations[1], and it has a backdoor in its custom kernel config that could be used to take over the system[2]. I'm not trying to crap on your efforts, it's just smart to vet any system even if they claim to be FOSS or open hardware friendly. [1] http://linux-sunxi.org/GPL_V…

Active mainlining of Allwinner chips is under way.[0]

I only use the devices with kernels from trustable sources, like Debian. The A20-Olinuxino-Micro works already quite good with Debian out of the box. It is even recommended by FreedomBox.[1]

Because mainling for the A64 isn't at a usable state right now, I'm holding back on buying a Teres-1.

[0] http://linux-sunxi.org/Linux_mainlining_effort

[1] https://wiki.debian.org/FreedomBox/Hardware

Re: LinuxBoot: Linux as Firmware

#78

Post by thudson »

BenjiWiebe wrote: post #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…

With LinuxBoot you can use any filesystem that Linux supports, not just FAT.

You can update boot entries by editing shell scripts, rather than manipulating opaque NVRAM variables.

You can run Linux applications straight from the ROM if you want to do that.

You can avoid legacy partitions entirely and use LVM for flexible volume management.

And...

You can build it yourself and verify that the reproducible build matches what others have built to ensure that the firmware is clean.

You can have the firmware attest to you via TOTP that it hasn't been changed.

You can have a fully encrypted disk, with secrets sealed in the TPM and only unsealed if the firmware is unmodified.

You can include device drivers for things that UEFI doesn't support.

You can use external hardware tokens like a Yubikey to sign the OS install and have the firmware validate the GPG signature.

Or what ever else you might want to do...

Re: LinuxBoot: Linux as Firmware

#79

Post by garmaine »

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.

The LinuxBoot kernel is designed to check downstream signed kernel images before loading. So it won’t load anything that isn’t signed.

I suggest watching the original Heads talk to understand the context and goal better.

Re: LinuxBoot: Linux as Firmware

#80

Post by Hello71 »

BenjiWiebe wrote: post #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 can now have a normal partition to put my boot loaders in rather than a hidden chunk at the beginning of the disk.

you can make a /boot with BIOS too. format it with FAT and nowadays all bootloaders can access it. in practice, I'm pretty sure GRUB can boot everything but Windows and Mac anyways, so it doesn't really matter.

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

again, grub handles this. in fact, it handles it much better than some firmwares, which usually have bugs relating to, among others, random rearrangement of boot order, failure to persist changes, and permanently adding entries for every flash drive you plug in. these have never happened to me with grub, and I do not expect them to. OTOH, I expect to see stupid bugs caused by firmware vendors de facto supporting single-drive Windows only, at least until the end of the PC platform as we know it.

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

I guess this is nice, but honestly three binaries wasn't significantly worse than two.

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

you can use GPT with BIOS too, it's just that MS doesn't feel like testing it so they lock it out for everybody.

Post reply on HN