No more boot loader: Please use the kernel instead

No more boot loader: Please use the kernel instead - DevConf.CZ 2024

Рет қаралды 12,387

DevConf

Күн бұрын

Пікірлер: 48

@IgorGuerrero 5 ай бұрын

The bootloader is one of the weirdest and scariest things to change in Linux.

@michaelodonnell5710 5 ай бұрын

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.

@iusearchbtw69 5 ай бұрын

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?"

@skinwalker69420 5 ай бұрын

Looks like my comment got deleted but you can already do that with an EFI stub

@tibbydudeza 5 ай бұрын

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.

@study9003 5 ай бұрын

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

@purpleidea 6 ай бұрын

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?

@tocadotux 5 ай бұрын

Which variant is more secure?

@Gooberpatrol66 5 ай бұрын

The bootloader still exists, it's just in the UEFI now

@FOREST10PL 5 ай бұрын

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?

@dustycarrier4413 5 ай бұрын

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.

@aahlala 5 ай бұрын

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.

@Nick-h3t3y 5 ай бұрын

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.

@BobHannent 5 ай бұрын

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.

@RaphaelBastosakaCoffnix 5 ай бұрын

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

@rapamune 5 ай бұрын

Can you elaborate for people who do not know about the disadvantages to a SHIM approach, and what an alternative would be?

@PragandSens 5 ай бұрын

some microsoft haterboi here, secure boot its actually secure, it introduces the concept of chain of trust, nmbl minimizes the surface area... dude comeon

@RaphaelBastosakaCoffnix 5 ай бұрын

@@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.

@RaphaelBastosakaCoffnix 5 ай бұрын

@@rapamune If your hardware can't store its own keys, using SHIM is prohibitive-upgrade your hardware immediately.

@thialfi2289 5 ай бұрын

@@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.

@roberthealey7238 5 ай бұрын

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.

@falsemcnuggethope 5 ай бұрын

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?

@jmennius 5 ай бұрын

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.

@jylpah 5 ай бұрын

@@jmennius This is btw my #1 reason to avoid ARMs and stick with x86.

@Vitis-n2v 5 ай бұрын

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

@study9003 5 ай бұрын

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

@replikvltyoutube3727 5 ай бұрын

This would be based if it allowed to update/reload something like android system linux kernel at runtime.

@necromancygood 5 ай бұрын

Kexec exists

@dustycarrier4413 5 ай бұрын

"Please stop using a bootloader. Please instead use our TotallyNotABootloaderTM" aahh presentation

@themadoneplays7842 5 ай бұрын

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.

@TheDiveO 5 ай бұрын

Still too complex: boot directly into Poettering, erm, systemd. The system _manager_ is the _system_, don't fuzz around with a kernel.

@jylpah 5 ай бұрын

Very welcome idea!

@marble_wraith 5 ай бұрын

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.

@JoeTaber 5 ай бұрын

This is so obvious it hurts. Why is my OS not bringing up the System that Operates my hardware?

@skinwalker69420 5 ай бұрын

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.

@DNFINST 5 ай бұрын

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.