SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
shrug, and I have 5.19.x kernel that never had an issue with elilo (in fact I never upgraded elilo). The fact that you do not have issues with GRUB, does not mean that a lot of users complain about it.
Probably Monsieur Spaier talks from the POV of Slint maintainer.
Did you remember that he maintains a Slackware derivative for physical challenged people?
If the blind persons (which are the target audience of Slint) have no issues with GRUB2, permit me to doubt that the regular Slackers will have.
Last edited by LuckyCyborg; 08-27-2022 at 12:30 PM.
If the blind persons (which are the target audience of Slint) have no issues with GRUB2, permit me to doubt that the regular Slackers will have.
As an aside grub-emu (not shipped in Slackware yet) comes handy, allowing to preview the grub-menu in an emulator before rebooting, for instance after an update of the config file, and to check each boot entry.
Even simpler the attached script just lists the boot entries. It's very basic, but handling sub-menus is in my TODO list. Run it as root or with sudo.
In Slint we display its output with w3m: being both a pager and a web browser it allows to move up and down with the arrow keys, which comes handy when using a screen reader.
Last edited by Didier Spaier; 08-27-2022 at 05:21 PM.
Reason: s/display it/display its output/
Distribution: VM Host: Slackware-current, VM Guests: Artix, Venom, antiX, Gentoo, FreeBSD, OpenBSD, OpenIndiana
Posts: 1,022
Rep:
There are three (at least) problems:
1) only AMD EPYC 7003 "Milan" should be affected by this issue because this is first AMD CPU that supports SEV-SNP. Earlier AMD CPU do not have this feature. Bug affects all cpus including Intel (which have SGX that is implemented already and is NOT causing problems).
2) why SEV-SNP is implemented at all if it was broken in 2021?
3) GRUB is not a better solution than elilo. Why replace tool that is simple and works with big complicated tool that already had serious security issues (e.g. boothole until 2020, in 2021 Debian reported UEFI SecureBoot vulnerabilities).
There are three (at least) problems:
1) only AMD EPYC 7003 "Milan" should be affected by this issue because this is first AMD CPU that supports SEV-SNP. Earlier AMD CPU do not have this feature. Bug affects all cpus including Intel (which have SGX that is implemented already and is NOT causing problems).
No matter what and how and what, facts are that that rotten ELILO was unable to boot the 5.19.x kernels, unless it was patched.
And there is any guarantee that that will NOT happen again with the kernel 6.1.x ? Nope, because the ELILO is not maintained anymore since 2014. Those are 8 (eight) years, buddy! EIGHT!
There is even a guarantee that the Slackware team will be able to patch the next ELILO boot issue? Nope.
Quote:
Originally Posted by Aeterna
2) why SEV-SNP is implemented at all if it was broken in 2021?
Ask Mr. Torvalds.
Quote:
Originally Posted by Aeterna
3) GRUB is not a better solution than elilo. Why replace tool that is simple and works with big complicated tool that already had serious security issues (e.g. boothole until 2020, in 2021 Debian reported UEFI SecureBoot vulnerabilities).
I think is really, but really ridiculous for us to talk about things like BootHole, considering that Slackware has no support at all for SecureBoot and any EFI binary can be executed at will by any EFI bootloader existing around. That's exactly what others calls a "huge security issue" while I seen that us we call this a "feature" . And "bootloader diversity" .
So, Slackware is ALWAYS affected by the worst conditions of BootHole security issue, no matter if you even use ELILO, because BootHole means ability of execution of unsecure/unverified EFI binaries. Just like in Slackware.
Why to replace "the simple tool" with something else? Because it's abandoned since 8 (eight) years and I do not seen Slackware to pay a team of programmers to take over whatever software development?
BTW, IF Slackware have associated programmers, I would love they to fix on ELILO that crazy issue of breaking sleep/hibernation on Wayland/Plasma5. You can believe that? IF you want proper hibernation on Wayland/Plasma5, you need to switch to GRUB2.
Last edited by LuckyCyborg; 08-27-2022 at 10:05 PM.
Distribution: VM Host: Slackware-current, VM Guests: Artix, Venom, antiX, Gentoo, FreeBSD, OpenBSD, OpenIndiana
Posts: 1,022
Rep:
It does not matter if Slackware was affected or not in the past by specific GRUB issue. It may happen next time.
The implementation of SEV-SNP is buggy so it needs to be fixed. Or next time when kernel will not boot with GRUB because of buggy kernel you will advocate removing GRUB?
Quote:
Boot Hole vulnerability is a buffer overflow (CVE-2020-10713) in the parser for the GRUB2 configuration file which can be used to trigger arbitrary code execution within the context of the GRUB2 process..... Examination of the GRUB2 source revealed that the fatal error handler actually does no more than log a console message and then return the calling module; however the calling modules are clearly coded with the assumption that a call to the fatal error handler will never return....Once all the updated components have been installed in the field, the UEFI disallow database will need to updated to prevent the vulnerable versions of the code being used in the future.
Looks like GRUB2 specific
Quote:
IF Slackware have associated programmers, I would love they to fix on ELILO that crazy issue of breaking sleep/hibernation on Wayland/Plasma5. You can believe that? IF you want proper hibernation on Wayland/Plasma5, you need to switch to GRUB2
I don't have this problem, maybe this is related to specific hardware setup
Meanwhile, on Paradise they did for the kernel 6.0-rc3
Code:
diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
index 52f989f6acc28..c93930d5ccbd0 100644
--- a/arch/x86/boot/compressed/sev.c
+++ b/arch/x86/boot/compressed/sev.c
@@ -277,6 +277,14 @@ void sev_enable(struct boot_params *bp)
bool snp;
/*
+ * bp->cc_blob_address should only be set by boot/compressed kernel.
+ * Initialize it to 0 to ensure that uninitialized values from
+ * buggy bootloaders aren't propagated.
+ */
+ if (bp)
+ bp->cc_blob_address = 0;
+
+ /*
* Setup/preliminary detection of SNP. This will be sanity-checked
* against CPUID/MSR values later.
*/
It does not matter if Slackware was affected or not in the past by specific GRUB issue. It may happen next time.
And I'm sure that this specific GRUB issue will be fixed. Because it's maintained.
The keyword there is "maintained"
Quote:
Originally Posted by Aeterna
The implementation of SEV-SNP is buggy so it needs to be fixed.
Let's "fix" the kernel because of the buggy bootloaders abandoned since long years!
Quote:
Originally Posted by Aeterna
Or next time when kernel will not boot with GRUB because of buggy kernel you will advocate removing GRUB?
When the GRUB2 will be abandoned since 8 years or so, and it will show its old age and various issues, probably I will advocate for another bootloader, still maintained.
Quote:
Originally Posted by Aeterna
Looks like GRUB2 specific
BUT, the end result is the same: execution of unsecure/unverified EFI binaries by GRUB.
Just like any EFI bootloader do in Slackware, thanks of the lack of support for SecureBoot.
The Zero EFI Boot Security politics of Slackware can be hardly beaten.
Quote:
Originally Posted by Aeterna
I don't have this problem, maybe this is related to specific hardware setup
BUT, it exists, thanks to rotten code of ELILO and there is no hope to be fixed, because ELILO is abandoned.
Honestly, I wonder how many years we should wait to move on? 10? 15? 20? 25?
In fact, what Slackware do there is like stubbornly insisting to ship XFree86 instead of Xorg.
Last edited by LuckyCyborg; 08-29-2022 at 04:28 AM.
The commit message and linked bug report shows that this problem was also hitting syslinux, QEMU with OVMF EFI booting with GRUB and certain hardware booting with GRUB.
So now a key variable is explicitly initialised. Looks like it was a kernel bug to me.
The commit message and linked bug report shows that this problem was also hitting syslinux, QEMU with OVMF EFI booting with GRUB and certain hardware booting with GRUB.
So now a key variable is explicitly initialised. Looks like it was a kernel bug to me.
Which is right in line with what Pat bisected and said was the problem.
This is not a GRUB2 issue, but rather a wrong usage of it. The fault is in user side, on Arch Linux case.
Obviously, when you update the GURB2 package, you should update also reinstall the GRUB2 on MBR or EFI partition. This is not GRUB2 specific, also you should do the same with LILO or ELILO, or any distribution shipped bootloader.
However, on Arch Linux (and Slackware) case, this reinstallation of GRUB2 on MBR, or EFI partition, should be done manually by the user.
Failing to do that, because GRUB2 dynamically read its config file, may result in boot failures - like those cited by you.
Last edited by LuckyCyborg; 08-29-2022 at 11:21 AM.
Normally, sanitize_boot_params() would be used to clear out such fields but that happens too late: sev_enable() may have already initialized it to a valid value that should not be zeroed out. Instead, have sev_enable() zero it out unconditionally beforehand.
* gives beloved poor little defenseless lilo a hug *
LILO (and ELILO or SYSLINUX) does not need hugs but a maintainer. How about someone of you to take over their development?
And if no one of you has the knowledge and/or the will to do this, there's always the possibility to pay a programmer to maintain them.
If you guys really want those bootloaders, why not open a Patreon to collect moneys and hire programmers for them?
From what I know, with 2000 dolars monthly, you can hire a decent C/C++ programmer from Eastern Europe. Probably you will pay less for hiring a Chinese or Indian one.
PS. I for one I have no knowledge on C/C++ and I do not look to find a job.
Last edited by LuckyCyborg; 08-29-2022 at 12:02 PM.
LILO (and ELILO or SYSLINUX) does not need hugs but a maintainer. How about someone of you to take over their development?
And if no one of you has the knowledge and/or the will to do this, there's always the possibility to pay a programmer to maintain them.
If you guys really want those bootloaders, why not open a Patreon to collect moneys and hire programmers for them?
From what I know, with 2000 dolars monthly, you can hire a decent C/C++ programmer from Eastern Europe. Probably you will pay less for hiring a Chinese or Indian one.
PS. I for one I have no knowledge on C/C++ and I do not look to find a job.
You can have such a programmer for free from western Europe, where everyone has more than 16 hours free time every workday and six weeks vacation every year.
No Chinese professionals for free software, please. They're always overloaded, working for 16 hours everyday and spitting out garbage code, introducing ten bugs when fixing one.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
