ฝัง
- เผยแพร่เมื่อ 22 มิ.ย. 2024
- Speaker(s): Marta Lewandowska
---
We are working on a new scheme to replace the GRUB bootloader with a fast, secure, Linux-based, user-space solution: nmbl (for no more boot loader).
Most people are familiar with GRUB, a powerful, flexible, fully-featured bootloader that is used on multiple architectures (x86_64, aarch64, ppc64le OpenFirmware). Although GRUB is quite versatile and capable, its features create complexity that is difficult to maintain, and that both duplicate and lag behind the Linux kernel while also creating numerous security holes. On the other hand, the Linux kernel, which has a large developer base, benefits from fast feature development, quick responses to vulnerabilities and greater overall scrutiny.
We (Red Hat boot loader engineering) will present our solution to this problem, which is to use the Linux kernel as its own bootloader. 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. All necessary drivers, filesystem support, and networking are already built in and code duplication is avoided.
We will showcase the work done so far, and ask you for your feedback and use cases.
---
Full schedule, including slides and other resources:
pretalx.com/devconf-cz-2024/s... - วิทยาศาสตร์และเทคโนโลยี
![บุษบา - เมนทอล [Official MV]](http://i.ytimg.com/vi/IGnWPokSEis/mqdefault.jpg)
"Please stop using a bootloader. Please instead use our TotallyNotABootloaderTM" aahh presentation
The bootloader is one of the weirdest and scariest things to change in Linux.
Typically if it's an idea from red hat, I'm not thrilled about it.
At least not until workers own the company. Which isn't likely with IBM owning red hat.
Nice work, but please allow me to remind you that the rule for speaking in situations like this is extremely simple, applicable to every context whether live or recorded: always, Always, ALWAYS, ***ALWAYS*** REPEAT THE AUDIENCE QUESTION BEFORE RESPONDING.
Two questions:
Can I create two /boot partitions (on different physical drives) with the same UKI on each, and that way if one drive dies, the other one will still let the machine boot?
Is PXE booting this kind of thing possible? Normally you template a kernel cmdline but it's inside the UKI?
putting SHIM in the boot stack and talking about security is like giving the keys to the vault to a thief and calling it protection. Anyone who understands security knows that SHIM is the ultimate joke in the security world
Can you elaborate for people who do not know about the disadvantages to a SHIM approach, and what an alternative would be?
some microsoft haterboi here, secure boot its actually secure, it introduces the concept of chain of trust, nmbl minimizes the surface area... dude comeon
@@PragandSens Relying on SHIM is a bad joke-you're trusting a closed-source giant like Microsoft to secure an open-source Linux system. This dependency increases your attack surface, complicates updates, and ultimately undermines the whole idea of Secure Boot. If Microsoft's keys get compromised, your trust chain collapses. It's laughable to see open-source advocates leaning on the very entity that historically opposed them. Ditch SHIM and secure your system properly.
@@rapamune If your hardware can't store its own keys, using SHIM is prohibitive-upgrade your hardware immediately.
@@rapamune I am very much not an expert on this but I'll attempt to explain it how I understand it. Because Windows is installed everywhere the Microsoft secure boot keys are installed in basically every UEFI so that they will automatically boot into Windows but pretty much nothing else (at least with secure boot enabled). If you want to be protected by secure boot when running another OS you have two options: use your own keys (will no longer boot into windows) or use a bootloader that is also signed by Microsoft's keys such as shim. Then when booting up you can choose between windows and shim and shim will then allow you to boot into a pre-approved application.
One disadvantage of using shim is that you are still using Microsofts secure boot keys. This means that you have left a door into your system for any software signed by the Microsoft keys and you are trusting them to keep the keys safe. If you don't plan on dual booting with windows, it's easy enough to setup your own secure boot keys using tools like sbctl and removes the risk of someone trying to boot your system with software you haven't personally approved. Personally I don't think this is worth worrying that much about since 1 - if you are an interesting enough target that someone is putting this effort into breaking into your system they will find something that works and 2 - if they have that level of access to your system there are almost certainly easier approaches they can take to get access to whatever information they want. I'd only worry about it if you're super security conscious but if you are then you definitely shouldn't be taking advice from me.
I mean sure, when i first know anything about OS in general i always had the same unanswered question "Why don't we just boot straight into the OS itself?"
Looks like my comment got deleted but you can already do that with an EFI stub
To load a custom OS setup - in the old days of Intel servers there were different approaches to incorporate multi CPU's and memory into a server which Microsoft did not support in NT.
That was before Intel/AMD standardized these concepts.
Each vendor like SGI and others supplied their own kernel addons so that Windows NT could start up and initialize the hardware properly.
Its just the standard begin like this , but dont think the uki is not like bootloader , its the same as the bootloader but its just tiny and contains the initramfs and the kernel in it , so you boot directlly , but there is the stub thing wich is the magic happen
I was expecting this to replace UEFI too, as that is extremely complex too.
For a virtual machine, could you not use something like CoreBoot? Or given that you know most of the state of the virtual machine manager, you could boot straight into the kernel.
I see all of what you indicated to be a somewhat radical concept. Wintel a.k.a. the Windows authorities do not encourage this at all with their software, or more to the point how OEMs help delegate BIOS frameworks in their hardware. Given genuine crypto concerns regarding computer and network security, this improvement alone makes a real case for moving to forcing them to allow all operating systems on personal computers within the realm of private area networks, without individuals having to change numerous settings in BIOS and hope that the responsible OEM or manufacturer supports their operating system preference.
You'd have to convince all the hardware vendors to distribute something else that's in opposition to Windows, that's not likely to happen.
Pre-Linux/x86 the boot loader was very minimal and the main goal was to get the kernel in and running with as little additional code as possible.
Examine retro hardware boot processes for details.
I don't understand the use-case here. systemd boot already exists, it can already boot UKI images. Even better, you can sign the UKI and not rely on SB Shims.
Sooo, why do we need this tool?
There is no point. It's not even using the kernel anymore than using SystemD Boot or GRUB is. It being in the kernel codebase is meaningless.
Would this make it easier to have distros run OOB on arm SBCs? Now they need to be customized and released by SBC vendors. Or is that a completely separate issue?
It is completely separate because the issue is with HW configuration discovery - something that is handled with ACPI on x86 but it is not present on ARM, so you have to have a device tree telling the kernel all about available devices.
@@jmennius This is btw my #1 reason to avoid ARMs and stick with x86.
Very welcome idea!
The bootloader still exists, it's just in the UEFI now
I still don't see how this will help anything. The only thing i see this as is a in kernel GRUB rewrite that's supposed to be lightweight but once you use this on real hardware that's full of bugs on the hardware and UEFI level you will see this project become just as bloated as GRUB because otherwise it will just not work on many configurations. I hope I'm wrong and I just completely misunderstood this from this short video but that's how i see it. I'll check this out again once it's tested on actual hardware. So gummiboot it is for now
I didnt see the video actually , but i have using UKI mounths now , its really good thing , you eliminate thd grub thing you just boot directlly from the firmware , i dont see possible bugs unless its a kernel bug , in that case grub it self wouldnot boot it , and the stub thing is light , and the uki simplify the proccess of using secure boot if you want , and also in archlinux for example it gived you the a simple choise to add a splasb screen at boot , for the systemd thing , dont usd it ! really ، if you using mkinitcoio/dracut , thier capable of making uki without the systemd bloat , finally to boot it you create an efi entry using efibootmgr
This would be based if it allowed to update/reload something like android system linux kernel at runtime.
Kexec exists
This is so obvious it hurts. Why is my OS not bringing up the System that Operates my hardware?
Because the kernel isn't the operating system. There's no practical advantage to putting a bootloader into the kernel unless you're trying to turn the kernel itself into the OS.
Still too complex: boot directly into Poettering, erm, systemd. The system _manager_ is the _system_, don't fuzz around with a kernel.
Make an alternative to ventoy and build on grub-emu with advanced functionality (like sounds and animations) people who rice will go nuts, and not just linux users, people doing windows sysadmin / sys-ops too.
Yes but what about dual booting? I mean, its bad enough that Grub has disabled OS prober, and you have to do complicated horseshit to dualboot using systemd-boot.
This will only give one more annoyance for potential new linux users not to use linux in the first place in fear of not being able to use another OS of their choice, even if that so happens to be windows.
Please replace the sysvinit instead
You saying that we shold replace the kernel with systemD?
- distro developers
done
lol this is pure insanity
This will only be used to make approved OS Kernels sanctioned by EFI Key holders.
it's still using the shim, why would it be different
Awesome presentation, but you deserve better audience. What the hell is wrong with these people, constantly coughing, smashing doors or farting. What is wrong with them? At least have some decency and respect the presenter … Jeez
No, this is fully to blame on the organization of the venue. The sounds you hear are 'normal people noises' that you'd also hear at other talks, movies or theaters. The problem is the mic placement and that it had to be way to sensitive to make the speaker audible.
In that regard, It also always amazes me how they can fck up the Q&A portion of these recordings every time. You can't hear any of the questions.
Why are redhat employees hell bent on destroying Linux? 😢
Replace systemd.Please..
It's called OpenRC bro you just gotta use Gentoo
bloat, just use efistub and use uefi as the bootloader.