Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by billyswong View Post

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


    • #22
      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.
      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


      • #23
        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.
        you dont need a bootloader like grub on EFI. unless you want encryption. And software encryption is better than relying on hardware you cant trust anyway. The issue is serving a password prompt before mounting an encrypted partition.
        Last edited by cj.wijtmans; 17 December 2023, 10:16 AM.

        Comment


        • #24
          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.
          dont portable drives also have EFI partition with exfat fs?

          Comment


          • #25
            Originally posted by cj.wijtmans View Post

            dont portable drives also have EFI partition with exfat fs?
            Please re-read what I was replying. Your point is totally irrelevant to the original discussion.

            Comment

            Working...
            X