What is Limine?
Limine (pronounced as demonstrated here) is a modern, advanced, portable, multiprotocol bootloader and boot manager, also used as the reference implementation for the Limine boot protocol.
CachyOS (from calamares they provide an option which one to choose grub or limine)
thoughts? @Patrick @arraybolt3 @HulaHoop
Checklist:
packages.debian.orgMost is probably some of:
So no, seems entirely unrealistic to replace GRUB in the next years.
I’m not really sure what about Limine would be better than GRUB off the top of my head. It’s… different than GRUB, I guess, but does it have any specific security focus that GRUB lacks? Does it use programming techniques that will make it intrinsically safer than GRUB? Is its development team trusted or reputable for their high-quality code?
If the answer to those questions is “no”, I would suspect Limine would be a downgrade from GRUB in terms of security.
Hypothetically, if we ported to Limine and then if GRUB improves support for GRUB Full Disk Encryption (encrypted /boot) would we flip flop back from Limine to GRUB?
To add:
/bootMaybe we can ask them about all the GRUB lack features we want and check if it exist, will be supported, or not.
IMHO we shouldn’t replace integral system components that are widely used and tested unless there is a compelling need to do so, such as supporting embedded platforms or avoiding serious vulnerabilities. Generally we want a system that just works so we can build innovations on top of it rather than fiddle with alternatives that introduce eccentricities and unexpected behavior.
It wouldn’t have been introduced if grub wasnt piece of garbage. But yeah i dont know if limine actually willing to fix what grub lacks specially with the focus on security and modernity aspects. Thats why i said it need to be checked.
I’ve worked on and contributed to GRUB upstream’s code, it’s generally quite good in my experience, and it is well-maintained from a security perspective AFAIK.
Limine was apparently created to implement a boot protocol that overcame the shortcomings of GRUB’s Multiboot protocol, according to:
This doesn’t concern us though because the Linux kernel uses its own boot protocol, which both Limine and GRUB have support for in addition to their native protocols:
Perhaps the difference between protocols would be relevant if we were creating the OS kernel ourselves, but in the context of Kicksecure we don’t really care as long as the OS boots right and can be secured well.
GNU Grub2 version number and vulnerabilities.
LulzSec BootHole.
And due to how much trash Grub is, we have articles like this:
" and strip out support for ““complex partition setups such as LVM, md-raid (except raid1), and LUKS-encrypted /boot”” because those were not tested nor used by the Ubuntu installer."
LOL so Ubuntu devs want to turn GRUB into a stripped down paper weight cuz “muh security”? I think that’s pretty idiotic. Perhaps they will go ahead and make yet another NIH clone of a basic system component in an attempt to influence the ecosystem as they’ve tried many times in the past.
The security “vulnerablities” reported are caused by Ubuntu shipping unnecessary drivers. As for secure boot being ineffective, it always was and will be because the real goal behind it is control over our computing by Microsoft, not to empower the user to hold the keys for their own system or verify its security. Also moving FDE to depend on TPM is a disaster. A proprietary component should never be trusted with a user’s keys
Limine or other alternatives are not necessarily more secure, just less popular and have less eyeballs on them than GRUB to uncover their own issues. There is a clear demand for GRUB’s functionality and any project that would attempt to go as far will encounter some bugs inevitably, The solution is to improve what we have and as the codebase matures, things will settle down CVE wise.
None of this information indicates that GRUB is “trash”. Every bug listed on “cvedetails” appears to have been fixed, which is great. BootHole was the first in an entirely new family of vulnerabilities when it was discovered, which led to strengthening Secure Boot itself, not just GRUB. Filesystem drivers and images are always going to be a risk, they are on every OS, which is why removing them from Secure Boot signed GRUB makes some sense.
Based on this concept nothing is bad, every software is great since vulnerabilities are getting fixed.
We have many vulnerabilities + Bloated code with tons of unnecessary functionalities (many backward support BS).
So hardening/minimizing Grub code or supporting an alternative or creating new project one of these is the answer for real secure future, current Grub is not meeting this criteria unless something gonna change in the development behavior.
A) no, some software just has unfixed vulnerabilities and is permanently unsafe to use. B) it is impossible to judge the safety of a particular application by CVE count alone, and very difficult to properly judge safety by CVE frequency. To illustrate, RetroShare has zero CVEs. Qubes OS, at the time of writing, has issued 114 security bulletins, each corresponding to a real vulnerability that could put the safety of a Qubes OS user at risk. Clearly then Qubes OS must be garbage compared to RetroShare, right? Yet Qubes OS is known for being the world’s safest widely deployed operating system, while a security auditor who reviewed RetroShare believed that the codebase lacked secure coding practice. Obviously this is not a direct comparison as Qubes OS is an operating system and RetroShare is a chat/social media app, but I think this still illustrates the point.
If a project’s most commonly used feature set is a frequent source of issues that put users at risk, it may be reasonable to consider switching to a different application. If a code audit shows that the code has been written carelessly, it is almost certainly reasonable to consider switching. To my awareness, GRUB is considered generally solid, even if it is not 100% bulletproof. That, combined with a willingness to quickly fix bugs, means that GRUB is non-ideal but still likely decent.
I was unable to find any third-party code audit of the Limine codebase. I also could not quickly find an audit of GRUB either. Of the two, GRUB is much more mature.
systemd-boot may be a suitable alternative for in the future, especially if it is signed by Microsoft’s keys for the sake of Secure Boot compatibility.
Trash software are not dead software or they dont fix their vulnerabilities, pidgin was not chosen to be inside whonix not because its dead but because its security trash.
Nobody said count alone, but severity and app design/bloated code as well, as i posted above.
If you want to compare it to qubes, should compare it to how many vulnerabilities affecting Qubes due to Qubes devs own code, not others. If vulnerability effecting whonix due to the kernel i cant blame whonix for that.
I dont have the right answer for what is the best alternative, but yeah future is not good for Grub if things kept like this.
How important is this issue versus others?
Trick question:
How did BootHole affect the security of Qubes OS?
For now not priority because no clear better replacement exist yet, but as you see from ubuntu and Grub alternatives, they are moving away from using it.
No secureboot support in Qubes yet, so the answer by the NSA:
If an endpoint does not have Secure Boot enabled, then the endpoint is already vulnerable to boot malware regardless of the GRUB2 vulnerability being present.
Intel/AMD64 booting will always remain messy because it necessarily is the first interaction layer with proprietary hardware and firmware.
See also article and discussion here:
In wiki chapter Security Mindset of Open Source Software Ecosystem I am arguing that security isn’t the primary goal of most Open Source projects. So unless a project explicitly states its security focus, I wouldn’t assume security being one of their priorities.
So please research why Limine has actually been founded rather making assumptions.
This is a bit similar to the systemd discussion.
As written in Non-Systemd - Systemd Development Discussion - #11 by Patrick - Development - Kicksecure Forums
GRUB is the default bootloader of the most popular Linux distributions. Ubuntu, Debian, Mint, Fedora, Kali, …
At this level of adoption, it is very much expected to find a lot issues, disagreements, criticism. That is very much to be expected.
Linux distributions cannot agree on a whole lot.
It’s easier to write code than other’s code.
There are many incentives to rewrite code:
Also related: Scattered Attention
[Half-sarcastic to have a fun write-up why there cannot be a perfect boot process on proprietary Intel/AMD64 firmware, highly popular, loved by everybody, criticized by none.]
GRUB is kinda awful because of all the code duplication. It’s a full kernel with display output support, keyboard support, drive support, file system drivers, and whatnot.
GRUB does that less perfect than the Linux kernel.
Wouldn’t it be great if we didn’t need GRUB and could use the Linux kernel instead? Yes, that would be great!
…but the devil in in the detail.
First there needs to be some sort of agreement which boot features are desirable.
Do we want encrypted /boot, an encrypted / better than GRUB Full Disk Encryption? Of course, some would want that.
Secure Boot? Of course!
Measured Boot? Sure!
Verified Boot? No brainer!
Network booting? Required in corporate contexts!
Quote Giving bootloaders the boot with nmbl [LWN.net]
Text in [ ] added by me.
Seems non-ideal. The proposal is to ditch GRUB (a bootloader) and use shim, a bootloader that was supposed to be minimal and handover to a “traditional” bootloader. Its readme states:
Yet, HTTP booting was added to shim.
So instead of GRUB carrying necessary complexity, now shim is supposed to carry the necessary complexity. Yet another GRUB rewrite considered.
There are a lot development decisions to be made.
Never say never but I can certainly say it will never be possible to find universal agreement on how to answer these questions among programmers.
And more hardware based complications…
And this kind of feature request:
Not that GRUB is perfect, but all proposals all have 1 thing in common: They’re imperfect. They often also contradict each other (use EFI firmware and unikernel versus use a bootloader). Some one to replace GRUB, others want “nmbl”.
Target audience is also very diverse. Laymen and power users. Laymen won’t know what a bootloader is and power users will criticize every boot process implementation.
Hardware support also matters. Apple bootloader only needs to support Apple devices, can design firmware, bootloader and operating system. But Linux desktop distributions typically want to be compatible with common hardware that comes with proprietary firmware.
