On Di, 09.05.23 15:04, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote: > > This makese no sense. If you want /boot to just be a subvolume of the > > rootfs btrfs, then this would imply it's also covered by the same > > security choices, i.e. encryption. We want to bind that sooner or > > later to things like TPM2, FIDO2, PKCS11. And that's simply not > > feasible from a boot loader environment. > > Windows and macOS do this, so it is feasible, the question is what > are the consequences of this and are we willing to live with them? They focus on a much more limited set of functionality. Also, are you volunteering to implement and maintain a full LUKS2, TPM2, FIDO2 and PKCS11 stack in UEFI mode? Good luck, man! And it's not getting any simpler. Next thing coming up is probably PassKey support, which means networking support. That's going to be fun in UEFI to support! I mean, these things tend to grow and become more complicated over time, and if you avoid Linux userspace then you make your life impossibly hard. And I really don't see Chris Murphy stepping up and maintaining that mess. Or are you? As someone who actually occasionally writes UEFI code: ffs, give up on the idea to reimplement complex auth protocols in UEFI mode! You want to do *less* stuff in UEFI, not pile on and pile on. Grub's reputation suffered because they are basically reimplementing a crappy version of Linux in their boot loader. Get yourself out of that Grub mindset, man! This idea appears so "out there" to me, I am sorry, but I somehow can't believe you seriously are proposing this. > One obvious consequence, it further creates dependency on a single > bootloader, GRUB. Or we need an independent project that provides an > EFI program for unlocking LUKS volumes within the pre-boot > environment, thus making plaintext view available to any bootloader. Sorry, this is *such* *a* *bad* *idea*. > > Hence, the place the kernel is loaded from (regardless if you call > > it /efi or /boot or /boot/efi, and regardless what fs it is) must > > be accessible from the boot loader easily, without requiring > > implementation of TPM2/FIDO2/PKCS11 hookup in the boot loader. > > I understand that might be difficult and something we don't want to > do for resource reasons, but there isn't a technical impediment for > it. Well, that's true, you can hack anything up that a Turing machine can execute and also run it in UEFI mode, but I seriously hope that you are not actually suggesting this. > FAT isn't resizable. The growth requirement for /boot is greater for > some use cases more than others, so there is pressure building > because it will create waste for some use cases and > underprovisioning in other use cases. Those unverprovisioned being > told they can't upgrade but need to reprovision to solve this is > kindof annoying. If you don't want to resize VFAT and XBOOTLDR is not enough to address this problem we can relatively easily extend XBOOTLDR to allow more than one additional such partition we can search through. The code in the boot loader is relatively straightforward. The limiting factor is more figuring out where to mount those. But seriously, you are making up synthetic probems. If ESP is too small add a large XBOOTLDR and I am pretty sure we'll be fine for a long long time before this comes an issue again. So long in fact it might never become. > Right. Hence Linux Boot. Dump all the toy drivers in favor of real > ones. And a real user space. I mean you understand that this just adds another chain to the boot process? if you do what you are proposing then you need to build a kernel that supports all that, i.e. all the complex storage, graphics and so on that you want to boot from, and thus you'll also have alrge images, and then what did you gain? You ave to put that in the ESP too, and the size limits still apply. It's illusionary to believe that the size constraints for a kernel + drivers + complex storage stack + crypto stack + auth stack would not apply to kernel that just runs in uefi mode instead of native mode... Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
