you are viewing a single comment's thread
view the rest of the comments
[–] -3 points 3 months ago (12 children)

IMO, broken ≠ vulnerable. Broken to me means it doesn't work. There's a difference, to me. 🤷‍♂️

  • source
  • hideshow 12 child comments
  • [–] 43 points 3 months ago (3 children)

    If the "working" definition is "is secure", and there's 11 ways in which it's not, is it not "insecure", aka. "not working" then?

  • source
  • parent
  • hideshow 3 child comments
  • [+] -9 points 3 months ago (2 children)

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

  • source
  • parent
  • hideshow 2 child comments
  • [–] 14 points 3 months ago (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 10 points 3 months ago (5 children)

    Secure boot is supposed to be a lock.

    Turns out there are 10 year old tricks that bypass that lock.

    A lock that cannot deny access to people without proper key... is a bad lock.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 1 point 3 months ago (2 children)

    Yes.

    Is UEFI shim = secure boot?

  • source
  • parent
  • hideshow 2 child comments
  • [–] 4 points 3 months ago* (1 child)

    No.

    Secure Boot is basically a 'lock', on the UEFI.

    UEFI - Shim is basically a 'lockpick'.

    UEFI is the first step in your computer booting, turning on.

    So, if Secure Boot is supposed to be a 'lock', that limits who can access the UEFI ... but it turns out that there are many, old, UEFI - Shims, that defeat that 'lock'... then Secure Boot is not a good 'lock'.

    I don't mean to be rude but it seems like there might be a bit of language confusion going on here... In English, a 'shim' is a kind of crude/simple tool that can be used to break or bypass some actual physical locks.

    So 'UEFI-Shim' basically means 'a thing that breaks into your UEFI'.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 3 months ago*

    I don't think there's a language barrier here. I'm fluent in English, and I know what a shim is, both IRL and in the software world. I've just not run into it in a boot loader context before. And I'm not really knowledgeable when it comes to secure boot, either. Just trying to understand. 🙂

    Are you sure that's a good phrasing though, "that breaks into your UEFI"?

    A shim is usually something that you use to add or modify functionality by interception, right? Like a middle-ware, almost. So these old shims, are they responsible for functionality that directly has to do with Secure Boot, or something else?

    If so, they are broken — i.e. not fulfilling their purpose.

    If something else, they are not broken. They are just breaking something else, or making it vulnerable.

    Am I making sense? Does it not make sense? Because after all, I don't know much about the details of the subject matter. 😁

  • source
  • parent