It seems to be bootloader season, because we’ve got another one – this time, a research project with very limited application for most people.
SentinelBoot is a cryptographically secure bootloader aimed at enhancing boot flow safety of RISC-V through memory-safe principles, predominantly leveraging the Rust programming language with its ownership, borrowing, and lifetime constraints. Additionally, SentinelBoot employs public-key cryptography to verify the integrity of a booted kernel (digital signature), by the use of the RISC-V Vector Cryptography extension, establishing secure boot functionality. SentinelBoot achieves these objectives with a 20.1% hashing overhead (approximately 0.27s additional runtime) when compared to an example U-Boot binary (mainline at time of development), and produces a resulting binary one-tenth the size of an example U-Boot binary with half the memory footprint.
↫ Lawrence Hunter
SentinelBoot is a project undertaken at the University of Manchester, and its goal is probably clear from the description: to develop a more secure bootloader for RISC V devices. An additional element is that they looked specifically at devices that receive updates over-the-air, like smartphones. In addition, scenarios where an attacker has physical access to the device in question were not considered, for obvious reasons – in such cases, the attacker can just replace the bootloader altogether anyway, and no amount of fancy Rust code is going to save you there.
The details of the implementation as described in the article are definitely a little bit over my head, but the gist seems to be that the project’s been able to achieve a much more secure boot process without giving up much in performance. This being a research project with an intentionally limited scope does mean it’s most just something that’ll immediately benefit all of us, but it’s these kinds of projects that can really push the state of the art and try out the viability of new ideas.
For now i will stick with Grub with enabled os-prober and such, RISC-V included. From time to time a new project emerges, claiming security and being modern and … I have nothing against that but somehow such solutions either don’t support things like multi-boot environments or do rely on buggy and closed source solutions … meanwhile i can install Grub on an USB drive or boot ISO from hard drive directly … Or pretty much every thought i had in the past Grub supported it without further ado. On top of that i don’t trust solutions like TPM or UEFI enough, to consider them safe. So in that regard i don’t have to give up Grub, as by ditching Grub and loading UKI directly i wouldn’t believe i am more secure then running Grub + FOSS. When you start to add binaries then it’s down to blind trust anyway. Maybe you go that extra mile “as pro” in for example server environment. To get some false sense of security. Relaying on solutions builds on top of gazillion vulnerable and closed source solutions in forms of some firmwares or software solutions baked in some chip. Claiming that is so much better then using Grub + FOSS from a trusted repository.
Geck,
Use whatever works for you, no problem. But as someone who believes in the “keep it simple, stupid” rule, grub is too overengineered for my tastes and I don’t find it better than simpler alternatives. Grub configurations files are needlessly complex. None of that’s warranted and I’d be hard pressed to find a more complex bootloader.
It is important to understand the type of exploits that cryptographically signed & verified boot loaders protect against. Consider what’s known as an “evil maid” attack and how a vanilla grub install is trivially vulnerable. I understand you might not be at high risk and might not care, but it can be a serious risk for targeted attacks. Claiming that secure bootloaders offers no securirty is false.
It depends. That is when we start talking about boot loaders 10 people will list 10 different solutions. Now, true, all get the job done in described fashion, still most of them are severely limited from general purpose operating system point of view. That is they simply don’t work in a lot of use cases. That is not KISS principle to me, lacking software. Or saying Grub is complex but systemd isn’t. Or UKI from the point of view to ditch Grub, not being complex solution. Anyway, as such they are not suitable for this task. As for signing and verifying software point of view. If it’s a FOSS solution then it’s rather OK by me, if it doesn’t get in my way, otherwise thanks but no thanks. It’s like with sandboxing. I don’t believe it works and it ever will, hence running FOSS without sandboxing is preferred choice by me. I trust it more that running sandboxed blobs. Supposedly secure in reality far from it.
Geck,
Huh? You’re going to need to be more specific than that. what use case specifically?
To be perfectly honest most (and maybe even all) of my boot problems have been under grub. Luckily most grub distros use UUIDs now, but remember how bad things were when grub made you specify disks by an arbitrary index in a fixed hard disk map? It was very common for grub to fail to locate the OS. Why they did that is beyond me since it was extremely fragile to disk changes. Just plugging in or removing disk often broke grub.
https://superuser.com/questions/629999/grub-hd-wrong-detection-mapping
https://askubuntu.com/questions/321862/grub2-points-to-the-wrong-harddisk-after-installing-one-more-harddisk
Ironically simpler bootloaders that didn’t overthink it just used the disk passed by the BIOS. This was far more robust since there was no any ambiguity which disk is being booted from when additional drives got installed.
The problem with alternate bootloaders comes from the fact that most distros only support grub now, but as an admin I prefer tools that embrace the KISS rule: simplicity is zen. Alas this message gets lost with a lot of modern software, it’s one of my gripes with systemd. Anyway that’s just me, I’m not preaching what anybody else should use for themselves.
I place a lot of value open source as well, but the way you are talking about security and foss makes them sound like opposites when they’re really two different dimensions. To the extent that you don’t trust the security in proprietary firmware, fair enough. However don’t you have to concede that whether you enable your motherboard’s security features or not you’re still dependent on the very proprietary firmware that you are criticizing?
As admin or a regular user i am fairly sure that you appreciate the simplicity of Grub, that is Grub taking the complexity away. Complexity that comes with simple boot loaders in a complex use case boot environments, proposed UEFI solutions included. With Grub it will likely just work, whatever you throw at it, that is on why your last issue with Grub is now more then a decade old. As for trusting UEFI, IMHO way to much CVEs and other bugs involved. I don’t know on why this got no coverage on this page: https://arstechnica.com/security/2024/07/secure-boot-is-completely-compromised-on-200-models-from-5-big-device-makers/. All the talk about signing and verifying and it’s basically a joke, then we have Microsoft claiming they will make Windows secure …. As far as i am concerned less UEFI and more Grub is way better solution. For signing and verifying i wouldn’t trust anything not open. On top of that with firmware such hardware usually remains vulnerable until reaching EOL, on where with (FOSS) software you get an update through your software updater and it’s fixed. As this is an article about RISC-V booting. Here is a nice article on how it works on RISC-V and one can even create a “Hello, world!” type of kernel and after boot it. https://popovicu.com/posts/risc-v-sbi-and-full-boot-process/
Note that with “real” kernel, you would still need a boot loader, such as Grub or SentinelBoot, to fetch and load the system into the memory. In case somebody read the above article and thought RISC-V doesn’t need it.
Geck,
You are not portraying my opinion in good faith.
Yes it works now and I’d even agree that it’s “good enough”. But that is not enough to convince me that grub’s complexity is warranted. Anyway, it’s just my own opinion.
The headline of the article you linked to is technically wrong. “Secure boot” was NOT broken, rather vendor keys were leaked as the article does goes on to explain. The distinction is subtle but very important. If I said “security of linux routers is completely broken” when a vendor’s root key is compromised, I’m willing to bet you’d have problems with the headline being misleading. It would be sort of true on one level but leaves readers with the wrong impression that linux itself is broken when it isn’t.
I’ll grant you that a compromised key IS a security problem. But your example says more about the mismanagement of keys than a fault with the underlying technology.
Good luck buying only devices with FOSS firmware, much less ones without an EOL, that is some very wishful thinking. Don’t get me wrong, I wish I lived in a world where that rang true 🙂
Very interesting link, thanks!
Bootloaders add flexibility after the BIOS hand off, but they’re not strictly necessary if an operating system is designed to load itself in a more direct fashion.
I feel that feature full and supporting advanced or even corner use case scenarios shouldn’t be labelled as complex in a way that it would imply complex is a bad thing, especially when it covers your use case. For example i don’t find KDE, although being much more complex, a lesser option compared to other desktop environments out there. Lets not forget UEFI is more complex compared to BIOS. Now if UEFI should cover most of Grub use cases, then it needs to be just as complex. As for firmware blob or FOSS Grub, to boot my kernel. I always tend to opt-in to more open solutions. As for secure boot and technicalities about that article, lets then just rather say it’s not secure on that 200 models from that 5 big device makers. So for that hardware is just boot. And for boot we have much better option out there, called Grub.
Geck,
I understand if the “keep it simple, stupid” philosophy is not your thing, to each their own! But by the same token you ought to admit that your preferences for grub may not apply to me. The KISS argument is NOT that complex solutions don’t work. They can work, but I would say that misses the point of simplicity being its own merit.
Say the tables were flipped and I was the one pointing you to new tool that you found too different/complex for your liking. You’d have to concede that my pointing out the fact that it supports your use case doesn’t automatically invalidate your preference for grub, right? That’s the point.
Grub can be considered more complex due to supporting more use cases. As such it was selected as default boot loader in many general purpose GNU/Linux distributions. One could still opt-out of using Grub and to set up some different use case that works (only) for them. And call that a KISS approach to booting the kernel. The same can be said for BIOS vs UEFI. Due to UEFI implementing more features and by doing that becoming more complex, compared to BIOS, it can now boot a kernel in some specific use cases. Now for people that don’t particularly care about FOSS and are OK with blobs, for them it likely makes sense if UEFI implements more and more features Grub already supports, to i guess boot Windows? For a FOSS advocate i feel that’s a rather short sighted, not to say ignorant stance, claiming on how ditching Grub over UEFI would make things so much better. Something like coreboot using Grub as a payload and the ability to flash the chip with updates, that is something i would actually trust. AFAIK things like Verified and Measured Boot are possible in such setups. So yeah, we can have FOSS down to the metal, even when it comes to such things as booting the kernel.
Geck,
Nope, it’s more complex than a boot loader needs to be to boot operating systems. Anyways I understand that we’re both set in our ways so I don’t expect to change your mind, but you should not expect to change mine either. Regardless of what you say I will prefer simplicity.
Because UEFI implemented or will implement all the features Grub provides? And you will then rather just rely on UEFI being flexible enough, to support all your use cases and to just work, when it comes to booting a kernel? Yikes, again big thanks to Grub developers, for keeping the booting phase of my hardware flexible, open and to just work regardless of the use case. As the last thing we need is people not knowledgable in this area to again fiddle with boot loaders, mostly supporting Windows loading. To make it work, that is to get to the web browser on a GNU/Linux distribution. That is in no way a KISS approach to booting a kernel. In addition no OEM claiming it’s about FOSS can rely on UEFI. So we still need a flexible and open solution. Purism for example investing in PureBoot, other vendors investing in Grub and adding support for verified boot … This is still needed regardless of what UEFI does or doesn’t do.
And then i read this: https://ghostwriteattack.com/. Time to i guess admit, hardware/software is inherently vulnerable. So good luck to you SentinelBoot.
Geck,
Good find.
It does say it’s just this one CPU and not a RISC-V problem in general…
Still unfortunate though.