The idea with LuLo is to remove the responsibility of parsing filesystems and formats, aside from the bare minimum necessities (eg: FAT32), from the bootloader itself. It is a needless duplication of efforts to have bootloaders support all possible filesystems and formats, and it leads to massive, bloated bootloaders as a result (eg: GRUB2).
What is needed is to simply make sure the bootloader is capable of reading its own files, configuration, and be able to load kernel/module files from disk. The kernel should be responsible for parsing everything else as it sees fit.
Simply put, this is unnecessary. Putting the kernel/modules in a readable FAT32 partition and letting LuLo know about their BLAKE3 checksums in the config file provides as much security as encrypting the kernel does.
While this is a pointless effort on legacy x86 BIOS, it is a reasonable expectation to secure the boot sequence on UEFI systems with Secure Boot. LuLo provides a way to modify its own EFI executable to bake in the BLAKE3 checksum of the config file itself. The EFI executable can then get signed with a key added to the firmware's keychain. This prevents modifications to the config file (and in turn the checksums contained there) from going unnoticed.
It is $year_following_2012 now and most PCs are equipped with UEFI and simply
won't boot without a FAT EFI system partition anyways.
It is not unreasonable to share the EFI system partition with the OS's /boot
and store kernels, initramfses, and any other files needed for boot there.
LuLo is specifically designed for LunaOS, which only uses the Limine protocol. Supporting multiple protocols adds complexity and attack surface with no benefit for our use case. If you need Multiboot or Linux boot support, use the upstream Limine bootloader.