Red Hat Looks For Feedback On Its New Initoverlayfs File-System Proposal

[caligula]

Jokes on them, I just compile in the stuff I need and skip initrd entirely.

(But yes, I do see how this would be helpful for the non-custom kernel peasantry)

For real men, the size of the kernel + ucode + firmware binary is something like 10-15 MB (zstd) for a standard desktop PC. xz is a bit smaller but slower.

[cjcox]

Been fun watching the thread. Just fyi, not going well for team Big Blue.

[CommunityMember]

(But yes, I do see how this would be helpful for the non-custom kernel peasantry)

Reducing the need for a (monster sized) initramfs to handle all the driver (and especially multiple version firmware) bloat, and storing it in the EFI partition (which, of course, typically needs to be vFAT) will be a good thing going forward. I am not sure this is the best/right approach, but it is, at least, an interesting way forward.

[Anux]

Isn't RedHead the company that tries to prevent everyone from benefiting from their work? And now they want feedback?

[Old Grouch]

Reducing the need for a (monster sized) initramfs to handle all the driver (and especially multiple version firmware) bloat, and storing it in the EFI partition (which, of course, typically needs to be vFAT) will be a good thing going forward. I am not sure this is the best/right approach, but it is, at least, an interesting way forward.

Another approach is using GRUB2 that can access an initramfs stored 'elsewhere'. The GRUB2 needs to have the necessary drivers linked/built in to access the other location in read-only mode. My grubx64.efi is 2.5 Megabytes. The amount of 'stuff' on my ESP is minimal. Everything else, including swap, is in a LUKS partition.

I just get uncomfortable storing a lot of system-critical stuff unencrypted on the ESP with its filesystem which is almost, but not quite, FAT32. (There are some small differences - see the specification available at https://uefi.org/specifications, section 13.3 of the current version (UEFI Specification Version 2.10)). My gut feeling is that there should be more robust error detection and correction features for the storage of the code used for booting devices.

[archkde]

That is compressed, with zstd.

How much stuff do you have in there? I have never seen an initrd that large in compressed form, on any distribution.

[billyswong]

Another approach is using GRUB2 that can access an initramfs stored 'elsewhere'. The GRUB2 needs to have the necessary drivers linked/built in to access the other location in read-only mode. My grubx64.efi is 2.5 Megabytes. The amount of 'stuff' on my ESP is minimal. Everything else, including swap, is in a LUKS partition.

I just get uncomfortable storing a lot of system-critical stuff unencrypted on the ESP with its filesystem which is almost, but not quite, FAT32. (There are some small differences - see the specification available at https://uefi.org/specifications, section 13.3 of the current version (UEFI Specification Version 2.10)). My gut feeling is that there should be more robust error detection and correction features for the storage of the code used for booting devices.

By logic we have to put disk decryption code in an unencrypted partition anyway. The problem is which module should such code be packaged in. The current mainstream method in Linux as I know is to have a separate unencrypted EXT4 /boot partition from FAT32-like /boot/efi partition, then let GRUB do the bare minimum of mounting basic EXT4 then pass the job to the Linux kernel in /boot, which then ask for password and decrypt the main partition(s) of the computer.

If we want to minimize code exposed in unencrypted manner, the solution will be putting decryption logic into the EFI portion of the GRUB bootloader (or any other flavor of bootloaders), then put the Linux kernel inside encrypted partition. But if we want to minimize code exposed in unchecksummed/unsigned manner, we can always add the checksum/signature examination code in bootloader, and run the check each time when the computer boot. The kernel being in FAT32 is not a problem as the checksum/signature file can be put together in this EFI partition too.

p.s. Oh we can also set the bootloader to do such a self-check to itself too. This won't help for malicious temperament but definitely good enough for accidental corruption.

[petete]

On Manjaro the initrd is 15M gzip compressed. There's also a fallback that is 79M.

[caligula]

The kernel being in FAT32 is not a problem as the checksum/signature file can be put together in this EFI partition too.

FAT32 won't even support basic POSIX semantics. Even the cheapest routers and toy SBCs come with better bootloaders than UEFI.

[billyswong]

FAT32 won't even support basic POSIX semantics. Even the cheapest routers and toy SBCs come with better bootloaders than UEFI.

You are comparing a standard for highest common factor versus implementations that don't need to care compatibilities. In theory a motherboard can support any better filesystem for EFI partition but OS makers can't rely on that in practice.