5 ms·

If I'm understanding correctly, it might help to point out that in spite of the title they are proposing a bootloader, which can still let you modify the cmdlin

If I'm understanding correctly, it might help to point out that in spite of the title they are proposing a bootloader, which can still let you modify the cmdline, boot to other OSs, etc. It's just that the bootloader is itself using the Linux kernel so it can do things like read all Linux filesystems for "free" without having to rewrite filesystem drivers.

garaetjjte 2y ago
It could kexec other kernels but probably won't be able to jump to other OS bootloaders after it already called ExitBootServices.
- TylerE 2y ago
  Theoretically, couldn't it just write to a "boot this image next time" field (is the legacy MBR area available?) and trigger a reboot?
  - adtac 2y ago
    The target image would need to reset that field so that a second reboot puts you back into the bootloader because otherwise you'll be stuck booting that image forever.
    - rcxdude 2y ago
      The image doesn't need to do it, that's how UEFI bootnext works: the firmware resets the flag before it loads the image.
  - garaetjjte 2y ago
    Well you could change default boot entry in efivars, but if you're relying on firmware for that why not use firmware provided boot menu anyway?
  - Arch-TK 2y ago
    The boot disk isn't guaranteed to be writable.
    - TylerE 2y ago
      Even after you’ve already installed a custom boot laser to it? I mean, I agree with you in principle, but we already have the chicken - can’t existence of the egg be assumed?
      - yjftsjthsd-h 2y ago
        Consider a DVD that's EFI bootable; we can have whatever bootloader we want on the disc but it is not physically writable
      - Arch-TK 2y ago
        Aside from the DVD issue mentioned in the other person's comment. I have a design for a SED OPAL based encryption setup where the system boots with a read-only boot partition and it only becomes RW as part of the initramfs running (although optionally you can just keep it RO until you need to write to it, but this requires buy-in from the package manager). I think network booting with EFI would also suffer from a similar problem.
- yjftsjthsd-h 2y ago
  This is being discussed more extensively in other comment threads but it sounds like maybe there's a way for it to just reboot but set a flag so the firmware boots into a different .efi next time (once).
  - p_l 2y ago
    You can set BootNext variable to number of BootXXX variable you want to use once for next boot.
- derefr 2y ago
  The sibling comments who think you need to jump back to EFI to solve this, are thinking in layer-ossified terms. This is Redhat proposing this, and they're perfectly confident in upstreaming kernel patches to make this happen. I would assume that in their proposed solution, the kernel would have logic to check for a CMDLINE flag (or rather, lack of any CMDLINE flags!) to indicate that it's operating in bootloader mode; and if decides that it is, then it never calls ExitBootServices. All the EFI stuff stays mapped for the whole lifetime of the kernel. (Also, given that they call this a "unified kernel image", I presume that in the case where the kernel decides to boot the same kernel image that's already loaded in memory as the bootloader, then nothing like a kexec needs to occur — rather, that's the point at which the kernel calls ExitBootServices (basically to say "I'm done with caring about being able to potentially boot into something else now"), and transitions from "phase 1 initramfs for running bootload-time logic" into "phase 2 initramfs to bootstrap a multi-user userland.")
  - garaetjjte 2y ago
    >and if decides that it is, then it never calls ExitBootServices That's unlikely, I think that would mean you cannot use native drivers, at which point you're just writing another bootloader. I suspect they only planning to kexec into target kernel, not chainloading other EFI bootloaders.
    - derefr 2y ago
      You're right (as I saw another comment cite the primary-source for); but I'm still curious now, whether there'd be a way to pull this off. > I think that would mean you cannot use native drivers Yes, that's right. > at which point you're just writing another bootloader But that's not necessarily true. Even if you could only use EFI boot+runtime services until you call ExitBootServices, in theory, an OS kernel could have a HAL for which many different pieces of hardware have an "EFI boot services driver" as well as a native driver; and where the active driver for a given piece of discovered hardware could be hotswapped "under" the HAL abstraction, atomically, without live HAL-intermediated kernel handles going bad — as long as the kernel includes a driver-to-driver state-translation function for the two implementations. So you could "bring up" a kernel and userland while riding on EFI boot services; and then the kernel would snap its fingers at some critical point, and it'd suddenly all be native drivers. Of course, Linux is not architected in a way that even comes close to allowing something like this. (Windows might be, maybe?) --- I think a more interesting idea, though, would come from slightly extending the UEFI spec. Imagine two calls: PauseBootServices and ResumeBootServices. PauseBootServices would stop all management of devices by the EFI (so, as with ExitBootServices, you'd have to be ready to take over such management) — but crucially, it would leave all the stuff that EFI had discovered+computed+mapped into memory during early boot, mapped into memory (and these pages would be read-only and would be locked at ring-negative-3 or something, so the kernel wouldn't have permission to unmap them.) If this existed, then at any time (even in the middle of running a multi-user OS!), the running kernel that had previously called PauseBootServices, could call ResumeBootServices — basically "relinquishing back" control over the hardware to EFI. EFI would then go about reinitializing all hardware other than the CPU and memory, taking over the CPU for a while the same way peripheral bring-up logic does at early boot. But when it's done with getting all the peripherals into known-good states, it would then return control to the caller[1] of ResumeBootServices, with the kernel now having transitioned into being an EFI app again. [1] ...through a vector of the caller's choice. To get those drivers back into being EFI boot services drivers before the kernel tries using them again, naturally. It's a dumb idea, mostly useless, thoroughly impractical to implement given how ossified EFI already is — but it'd "work" ;)
kragen 2y ago
you seem to be saying that they are using two separate kernels, one for the bootloader and one for the final boot target the title text says 'Loaded by the EFI stub on UEFI, and packed into a unified kernel image (UKI), the kernel, initramfs, and kernel command line, contain everything they need to reach the final boot target' which sounds like they're not talking about using two separate kernels, one for the bootloader and one for the final boot target, but rather only one single kernel. possibly that is not the case because the actual information is hidden in a video i haven't watched https://news.ycombinator.com/item?id=40909165 https://news.ycombinator.com/item?id=40909165 seems to confirm that they are indeed not saying what you thought edit: they're proposing both configurations
- samatman 2y ago
  > It's just that the bootloader is itself using the Linux kernel This sentence does not say "the bootloader is itself another, separate, Linux kernel", so I'm not seeing him saying what you're saying he seems to be saying.
  - kragen 2y ago
    although you stated your comment less aggressively, you don't have nmstoker's excuse of possible ignorance; you must have already known what i said in this comment: https://news.ycombinator.com/item?id=40911469 https://news.ycombinator.com/item?id=40911469
- comex 2y ago
  I watched the video. They have two different configurations, one where there’s only one kernel, one where there are indeed two separate kernels with one kexec’ing to the other.
  - kragen 2y ago
    thank you for your sacrifice and for the resulting correction to my error
    - deleted 2y ago
cool_beanz 2y ago
You can have command line parameters baked into the EFISTUB. I also have two kernels, so there's two UKIs on /efi, and I have both added as separate boot options in BIOS.

garaetjjte 2y ago

It could kexec other kernels but probably won't be able to jump to other OS bootloaders after it already called ExitBootServices.

TylerE 2y ago
Theoretically, couldn't it just write to a "boot this image next time" field (is the legacy MBR area available?) and trigger a reboot?
- adtac 2y ago
  The target image would need to reset that field so that a second reboot puts you back into the bootloader because otherwise you'll be stuck booting that image forever.
  - rcxdude 2y ago
    The image doesn't need to do it, that's how UEFI bootnext works: the firmware resets the flag before it loads the image.
- garaetjjte 2y ago
  Well you could change default boot entry in efivars, but if you're relying on firmware for that why not use firmware provided boot menu anyway?
- Arch-TK 2y ago
  The boot disk isn't guaranteed to be writable.
  - TylerE 2y ago
    Even after you’ve already installed a custom boot laser to it? I mean, I agree with you in principle, but we already have the chicken - can’t existence of the egg be assumed?
    - yjftsjthsd-h 2y ago
      Consider a DVD that's EFI bootable; we can have whatever bootloader we want on the disc but it is not physically writable
    - Arch-TK 2y ago
      Aside from the DVD issue mentioned in the other person's comment. I have a design for a SED OPAL based encryption setup where the system boots with a read-only boot partition and it only becomes RW as part of the initramfs running (although optionally you can just keep it RO until you need to write to it, but this requires buy-in from the package manager). I think network booting with EFI would also suffer from a similar problem.
yjftsjthsd-h 2y ago
This is being discussed more extensively in other comment threads but it sounds like maybe there's a way for it to just reboot but set a flag so the firmware boots into a different .efi next time (once).
- p_l 2y ago
  You can set BootNext variable to number of BootXXX variable you want to use once for next boot.
derefr 2y ago
The sibling comments who think you need to jump back to EFI to solve this, are thinking in layer-ossified terms. This is Redhat proposing this, and they're perfectly confident in upstreaming kernel patches to make this happen. I would assume that in their proposed solution, the kernel would have logic to check for a CMDLINE flag (or rather, lack of any CMDLINE flags!) to indicate that it's operating in bootloader mode; and if decides that it is, then it never calls ExitBootServices. All the EFI stuff stays mapped for the whole lifetime of the kernel. (Also, given that they call this a "unified kernel image", I presume that in the case where the kernel decides to boot the same kernel image that's already loaded in memory as the bootloader, then nothing like a kexec needs to occur — rather, that's the point at which the kernel calls ExitBootServices (basically to say "I'm done with caring about being able to potentially boot into something else now"), and transitions from "phase 1 initramfs for running bootload-time logic" into "phase 2 initramfs to bootstrap a multi-user userland.")
- garaetjjte 2y ago
  >and if decides that it is, then it never calls ExitBootServices That's unlikely, I think that would mean you cannot use native drivers, at which point you're just writing another bootloader. I suspect they only planning to kexec into target kernel, not chainloading other EFI bootloaders.
  - derefr 2y ago
    You're right (as I saw another comment cite the primary-source for); but I'm still curious now, whether there'd be a way to pull this off. > I think that would mean you cannot use native drivers Yes, that's right. > at which point you're just writing another bootloader But that's not necessarily true. Even if you could only use EFI boot+runtime services until you call ExitBootServices, in theory, an OS kernel could have a HAL for which many different pieces of hardware have an "EFI boot services driver" as well as a native driver; and where the active driver for a given piece of discovered hardware could be hotswapped "under" the HAL abstraction, atomically, without live HAL-intermediated kernel handles going bad — as long as the kernel includes a driver-to-driver state-translation function for the two implementations. So you could "bring up" a kernel and userland while riding on EFI boot services; and then the kernel would snap its fingers at some critical point, and it'd suddenly all be native drivers. Of course, Linux is not architected in a way that even comes close to allowing something like this. (Windows might be, maybe?) --- I think a more interesting idea, though, would come from slightly extending the UEFI spec. Imagine two calls: PauseBootServices and ResumeBootServices. PauseBootServices would stop all management of devices by the EFI (so, as with ExitBootServices, you'd have to be ready to take over such management) — but crucially, it would leave all the stuff that EFI had discovered+computed+mapped into memory during early boot, mapped into memory (and these pages would be read-only and would be locked at ring-negative-3 or something, so the kernel wouldn't have permission to unmap them.) If this existed, then at any time (even in the middle of running a multi-user OS!), the running kernel that had previously called PauseBootServices, could call ResumeBootServices — basically "relinquishing back" control over the hardware to EFI. EFI would then go about reinitializing all hardware other than the CPU and memory, taking over the CPU for a while the same way peripheral bring-up logic does at early boot. But when it's done with getting all the peripherals into known-good states, it would then return control to the caller[1] of ResumeBootServices, with the kernel now having transitioned into being an EFI app again. [1] ...through a vector of the caller's choice. To get those drivers back into being EFI boot services drivers before the kernel tries using them again, naturally. It's a dumb idea, mostly useless, thoroughly impractical to implement given how ossified EFI already is — but it'd "work" ;)

kragen 2y ago

you seem to be saying that they are using two separate kernels, one for the bootloader and one for the final boot target the title text says 'Loaded by the EFI stub on UEFI, and packed into a unified kernel image (UKI), the kernel, initramfs, and kernel command line, contain everything they need to reach the final boot target' which sounds like they're not talking about using two separate kernels, one for the bootloader and one for the final boot target, but rather only one single kernel. possibly that is not the case because the actual information is hidden in a video i haven't watched https://news.ycombinator.com/item?id=40909165 https://news.ycombinator.com/item?id=40909165 seems to confirm that they are indeed not saying what you thought edit: they're proposing both configurations

samatman 2y ago
> It's just that the bootloader is itself using the Linux kernel This sentence does not say "the bootloader is itself another, separate, Linux kernel", so I'm not seeing him saying what you're saying he seems to be saying.
- kragen 2y ago
  although you stated your comment less aggressively, you don't have nmstoker's excuse of possible ignorance; you must have already known what i said in this comment: https://news.ycombinator.com/item?id=40911469 https://news.ycombinator.com/item?id=40911469
comex 2y ago
I watched the video. They have two different configurations, one where there’s only one kernel, one where there are indeed two separate kernels with one kexec’ing to the other.
- kragen 2y ago
  thank you for your sacrifice and for the resulting correction to my error
  - deleted 2y ago

cool_beanz 2y ago

You can have command line parameters baked into the EFISTUB. I also have two kernels, so there's two UKIs on /efi, and I have both added as separate boot options in BIOS.