4 ms·

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

hugelgupf 9y ago
See https://news.ycombinator.com/item?id=16259776 https://news.ycombinator.com/item?id=16259776
alerighi 9y ago
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.
- anderspitman 9y ago
  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.
  - hugelgupf 9y ago
    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.
  - andyjpb 9y ago
    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.
    - thudson 9y ago
      The LinuxBoot kernel establishes a hardware root of trust with the TPM and measures the ROM before bringing up any IO devices, so when it connects to the network it is able to perform a remote attestation as to its state. This way the hosting provider or customer can decide to not provision a node that has somehow been modified by a prior tenant. For a network booting scenario the LinuxBoot server can use GPG to validate the signature on the kernel that it receives over the network. Additionally, secrets can be sealed in the TPM and only unlocked if the received kernel matches the expected one (and if the local firmware is unmodified).
  - garmaine 9y ago
    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.
Cyberdog 9y ago
It's Linux. Linux all the way down.
- no_identd 9y ago
  Linux is written in C, not Lisp. So no, not really. Unfortunately.
e12e 9y ago
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?
- hugelgupf 9y ago
  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...
- kazinator 9y ago
  > 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.
mixmastamyk 9y ago
Flexibility. So can update the OS easily. To have the choice of running Windows or BSD, etc.

See https://news.ycombinator.com/item?id=16259776 https://news.ycombinator.com/item?id=16259776

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.

anderspitman 9y ago
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.
- hugelgupf 9y ago
  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.
- andyjpb 9y ago
  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.
  - thudson 9y ago
    The LinuxBoot kernel establishes a hardware root of trust with the TPM and measures the ROM before bringing up any IO devices, so when it connects to the network it is able to perform a remote attestation as to its state. This way the hosting provider or customer can decide to not provision a node that has somehow been modified by a prior tenant. For a network booting scenario the LinuxBoot server can use GPG to validate the signature on the kernel that it receives over the network. Additionally, secrets can be sealed in the TPM and only unlocked if the received kernel matches the expected one (and if the local firmware is unmodified).
- garmaine 9y ago
  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.

Cyberdog 9y ago

It's Linux. Linux all the way down.

no_identd 9y ago
Linux is written in C, not Lisp. So no, not really. Unfortunately.

e12e 9y ago

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?

hugelgupf 9y ago
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...
kazinator 9y ago
> 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.

mixmastamyk 9y ago

Flexibility. So can update the OS easily. To have the choice of running Windows or BSD, etc.