3 ms·

I will translate the doublespeak from redhat, which is similar to how they started to push systemd (really). > [grub] features create complexity that is diffic

I will translate the doublespeak from redhat, which is similar to how they started to push systemd (really). > [grub] features create complexity that is difficult to maintain, and that both duplicate and lag behind the Linux kernel while also creating numerous security holes. No mention of the alternatives. No mention how useful are those features. Handwaiving "security" arguments. > Loaded by the EFI stub All the talk about booting the kernel directly is moot, because by this they mean "we will use systemd-boot" ;) IMHO, this is part of the RH wider push for PKCS11/TPM2/FIDO2 stuff. So it is not really fixing boot loader, as it is standardizing on their bootloader "as the correct one" but using the kernel reputation on the double speak. Just like they pushed the equivalent of https://www.tenforums.com/attachments/tutorials/195499d1531424111t-windows-admin-center-centrally-manage-all-your-windows-10-pcs-image.png https://www.tenforums.com/attachments/tutorials/195499d15314... as the interface of init. (i'm not salty on systemd, in fact i already use bootd even. but if you cannot see how systemctl is the same UX as that, you are blind)

1oooqooq 2y ago
I should say *the joint RH/Microsoft/et al wider push for PKCS11/TPM2/FIDO2 stuff
deleted 2y ago
[deleted]
rini17 2y ago
EFI stub is an existing kernel feature, not related to systemd-boot. Of course, everything can be wired together with systemd.
- 1oooqooq 2y ago
  but it doesn't cover any of the unmentionable features that are so bad on grub. they will either be implemented in the kennel or the stub, because well, people will need dual boot, weird crypto, etc. exactly like happened with systemd. all the complexity was ignored.. then bolted on. do you miss crontab -e?
  - rini17 2y ago
    I do miss the ability to fix thing easily when crontab -e breaks. Oh, but systemd never breaks, okay.
    - 1oooqooq 2y ago
      crontab -e broke? you are special :) my point is that the alternative to "crontab -e" is writting two files with 10~20 lines in difficult to remember paths. it's impossible to do without a webbrowser nearby.
abofh 2y ago
To be fair, it's similar because it's the problem people wanted solved - start this thing at boot, if it dies, restart it. I know rcS.d didn't handle the 'restart it', but even for the lowliest desktop user, if they've installed a daemon, and configured it to start, it more or less implies they'd like it to keep running. Systemctl looks a lot like a modern init on another OS because a modern init on any OS looks a lot the same. Whether it should spawn 1800 subprojects is a different debate, but I for one am much happier maintaining trivial .ini like files than trying to teach the new engineer bash.
collinmanderson 2y ago
systemd-boot comes up in the Q&A at 29:50. (The main problem nmbl is trying to solve is code-duplication with the kernel and therefore security issue duplication, and just like grub or any of the alternatives, systemd-boot duplicates code that's already in the kernel. The security holes will exist in any case, but the goal is to reduce security hole duplication by reusing as much of the kernel as possible, rather than creating something separate. They also plan on reuseing grub's menu code, so it will have the exact same menu as grub.) > The question is: that there are CVEs everywhere, we're not unique in this sense, and whether we would use systemd-boot. > So, systemd-boot, it also works only on UEFI, and I believe that the plans are to keep it that way. > Ultimately, the thing is that the kernel CVEs will get fixed no matter what, the question is: do we want to have more work fixing more CVEs. The kernel has a lot of developers, has very high visibility, and they're able to fix the CVEs in a reasonable time period. And, those aren't going to going to go away, the kernel CVEs aren't going to go away, whether we do this or not. > Systemd-boot, any boot loader, that aims to replicate the things that the kernel does is ultimately going to run into the same problems as grub. We're going to have the font CVEs, we're going to have filesystem and storage and memory allocation bugs. All of that stuff is going to exist in whatever boot loader. > Again, for an individual user, if you want to install systemd-boot, great, go ahead and use it. It's good, it works. But as a general option it's just going to have the same issues, unfortunately.
- joveian 2y ago
  This seems like it could be a good use of rump kernels, although I don't think anyone has made a bootloader based on NetBSD rump yet. I've heard of efforts to rumpify Linux but I don't know if they are continuing. This seems like it could offer the benefits of each approach. The rump kernel paper has this brief paragraph on bootloaders: > The lowest possible target for the rump kernel hypercall layer is ﬁrmware and hardware. This adaption would allow the use of anykernel drivers both in bootloaders and lightweight appliances. A typical ﬁrmware does not provide a thread scheduler, and this lack would either mandate limited driver support, i.e. running only drivers which do not create or rely on kernel threads, or the addition of a simple thread scheduler in the rump kernel hypervisor. If there is no need to run multiple isolated rump kernels, virtual memory support is not necessary.

1oooqooq 2y ago

I should say *the joint RH/Microsoft/et al wider push for PKCS11/TPM2/FIDO2 stuff

deleted 2y ago

[deleted]

rini17 2y ago

EFI stub is an existing kernel feature, not related to systemd-boot. Of course, everything can be wired together with systemd.

1oooqooq 2y ago
but it doesn't cover any of the unmentionable features that are so bad on grub. they will either be implemented in the kennel or the stub, because well, people will need dual boot, weird crypto, etc. exactly like happened with systemd. all the complexity was ignored.. then bolted on. do you miss crontab -e?
- rini17 2y ago
  I do miss the ability to fix thing easily when crontab -e breaks. Oh, but systemd never breaks, okay.
  - 1oooqooq 2y ago
    crontab -e broke? you are special :) my point is that the alternative to "crontab -e" is writting two files with 10~20 lines in difficult to remember paths. it's impossible to do without a webbrowser nearby.

abofh 2y ago

To be fair, it's similar because it's the problem people wanted solved - start this thing at boot, if it dies, restart it. I know rcS.d didn't handle the 'restart it', but even for the lowliest desktop user, if they've installed a daemon, and configured it to start, it more or less implies they'd like it to keep running. Systemctl looks a lot like a modern init on another OS because a modern init on any OS looks a lot the same. Whether it should spawn 1800 subprojects is a different debate, but I for one am much happier maintaining trivial .ini like files than trying to teach the new engineer bash.

collinmanderson 2y ago

systemd-boot comes up in the Q&A at 29:50. (The main problem nmbl is trying to solve is code-duplication with the kernel and therefore security issue duplication, and just like grub or any of the alternatives, systemd-boot duplicates code that's already in the kernel. The security holes will exist in any case, but the goal is to reduce security hole duplication by reusing as much of the kernel as possible, rather than creating something separate. They also plan on reuseing grub's menu code, so it will have the exact same menu as grub.) > The question is: that there are CVEs everywhere, we're not unique in this sense, and whether we would use systemd-boot. > So, systemd-boot, it also works only on UEFI, and I believe that the plans are to keep it that way. > Ultimately, the thing is that the kernel CVEs will get fixed no matter what, the question is: do we want to have more work fixing more CVEs. The kernel has a lot of developers, has very high visibility, and they're able to fix the CVEs in a reasonable time period. And, those aren't going to going to go away, the kernel CVEs aren't going to go away, whether we do this or not. > Systemd-boot, any boot loader, that aims to replicate the things that the kernel does is ultimately going to run into the same problems as grub. We're going to have the font CVEs, we're going to have filesystem and storage and memory allocation bugs. All of that stuff is going to exist in whatever boot loader. > Again, for an individual user, if you want to install systemd-boot, great, go ahead and use it. It's good, it works. But as a general option it's just going to have the same issues, unfortunately.

joveian 2y ago
This seems like it could be a good use of rump kernels, although I don't think anyone has made a bootloader based on NetBSD rump yet. I've heard of efforts to rumpify Linux but I don't know if they are continuing. This seems like it could offer the benefits of each approach. The rump kernel paper has this brief paragraph on bootloaders: > The lowest possible target for the rump kernel hypercall layer is ﬁrmware and hardware. This adaption would allow the use of anykernel drivers both in bootloaders and lightweight appliances. A typical ﬁrmware does not provide a thread scheduler, and this lack would either mandate limited driver support, i.e. running only drivers which do not create or rely on kernel threads, or the addition of a simple thread scheduler in the rump kernel hypervisor. If there is no need to run multiple isolated rump kernels, virtual memory support is not necessary.