• Victor@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    9 hours ago

    “Being secure” doesn’t seem to be the primary function of a “UEFI shim”, so no? 🤷‍♂️

    • urushitan 漆たん@kakera.kintsugi.moe
      link
      fedilink
      English
      arrow-up
      10
      ·
      9 hours ago

      Well considering that the “UEFI Shim’s” role is to sit in between a Microsoft owned certificate signing chain, it is certainly part of it’s primary role.

      With Linux distributions supporting UEFI Secure Boot, the above-described Secure Boot mechanism built around Microsoft keys introduces some challenges. Every Linux distribution generates its own bootloader binaries, and each of them has a different hash. Getting every Linux bootloader signed directly by Microsoft would be slow, bureaucratic, and impractical (if not impossible) to maintain across all Linux distributions.

      The solution to this problem is a shim: a small, minimal first-stage bootloader that Microsoft can vet and sign once, and which then creates a secondary trust anchor for the rest of the Linux distribution-specific boot stack – usually GRUB 2 and the Linux kernel. This trust anchor is another certificate, referred to as a vendor certificate (managed by the distribution vendor), added to the shim binary before it is signed by Microsoft.