Originally posted by billyswong
View Post
Announcement
Collapse
No announcement yet.
Red Hat Looks For Feedback On Its New Initoverlayfs File-System Proposal
Collapse
X
-
Originally posted by caligula View Post
I'm just saying that this system is perhaps even worse than legacy BIOS. The legacy BIOS only assumes that the boot drive has a 512 byte MBR block. No requirements for file systems. Much more flexible.
Comment
-
Originally posted by billyswong View Post
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.Last edited by cj.wijtmans; 17 December 2023, 10:16 AM.
Comment
-
Originally posted by billyswong View Post
For that regards UEFI allows, in theory, the same portable boot drive to boot up both ARM64 and AMD64 computers (and/or any other architectures). So I would call it more complexity for more flexibility.
Comment
Comment