4 ms·

This thing right here makes me unconfortable. I don't want Microsoft signatures or any other company for what matter to be involved in my boot process. > The U

This thing right here makes me unconfortable. I don't want Microsoft signatures or any other company for what matter to be involved in my boot process. > The UEFI firmware invokes a piece of code called "shim" (which is stored in the EFI System Partition — the "ESP" — of your system), that more or less is just a list of certificates compiled into code form. The shim is signed with the aforementioned Microsoft key, that is built into all PCs/laptops.

amarshall 5y ago
Almost all UEFI firmware allows replacing the default public keys with your own, and then you can sign everything yourself with private keys only you possess.
- Foxboron 5y ago
  In theory. But part of the UEFI boot chain is Optional ROM files stored on hardware. Most commonly found on dedicated graphics cards and other hardware. All of these files need to be authenticated, and currently signed by Microsoft or the OEM vendor. A modern Lenovo Thinkpad T14 Gen 2 laptop has 7 OpROM files. If validation fails for the GFX card you are essentially "soft bricking" the device since the GFX card won't work.
  - g_p 5y ago
    An idea I just had around this, for if you run your own PK/KEK/DB chain - is it feasible to "dump" these Option ROMs? If so, you should be able to whitelist their sha256 hashes in your DB database, since the DB can contain an allow-list of hashes, as well as an allow-list of public keys. I'm not familiar with how to view relevant Option ROMs, but if you can "dump" them in the format they will be verified in, you should be able to put those into your DB database. Perhaps there could even be an open/peer-vouched crowdsourced set of such DB entries maintained for popular systems?
    - Foxboron 5y ago
      sysfs doesn't like some optionroms, so using the rom files from there wont work in some cases. Apparently they can be stored in an ACPI table.. but I haven't looked at it. Another alternative is to read the TPM2 eventlog. It should record OptionROM checksums found during boot. $ tpm2_eventlog ./t14_eventlog | grep "BOOT_SERVICES_DRIVER" | wc -l 7 This is essentially what me and Trammell Hudson has been thinking about. But I don't have any available machines to test this with, and I haven't gotten around to setting up a QEMU vm to test out this theory. https://github.com/Foxboron/sbctl/issues/85#issuecomment-886539689 https://github.com/Foxboron/sbctl/issues/85#issuecomment-886...
      - g_p 5y ago
        Good idea RE the TPM event log - that should show the definitive perceived hash of the option ROM. Will need to see if I have any computers that require an Option ROM - somehow I suspect shipped-with-Linux Dell XPS laptops aren't going to be good test candidates.
  - blibble 5y ago
    I completely replace the entire set of secure boot keys with my own (no MS keys at all) for my desktop PC I had to sign the graphics card option ROM digest myself (which was a pain) however for my Thinkpad none of this was necessary as the firmware was stored inside the UEFI image

amarshall 5y ago

Almost all UEFI firmware allows replacing the default public keys with your own, and then you can sign everything yourself with private keys only you possess.

Foxboron 5y ago
In theory. But part of the UEFI boot chain is Optional ROM files stored on hardware. Most commonly found on dedicated graphics cards and other hardware. All of these files need to be authenticated, and currently signed by Microsoft or the OEM vendor. A modern Lenovo Thinkpad T14 Gen 2 laptop has 7 OpROM files. If validation fails for the GFX card you are essentially "soft bricking" the device since the GFX card won't work.
- g_p 5y ago
  An idea I just had around this, for if you run your own PK/KEK/DB chain - is it feasible to "dump" these Option ROMs? If so, you should be able to whitelist their sha256 hashes in your DB database, since the DB can contain an allow-list of hashes, as well as an allow-list of public keys. I'm not familiar with how to view relevant Option ROMs, but if you can "dump" them in the format they will be verified in, you should be able to put those into your DB database. Perhaps there could even be an open/peer-vouched crowdsourced set of such DB entries maintained for popular systems?
  - Foxboron 5y ago
    sysfs doesn't like some optionroms, so using the rom files from there wont work in some cases. Apparently they can be stored in an ACPI table.. but I haven't looked at it. Another alternative is to read the TPM2 eventlog. It should record OptionROM checksums found during boot. $ tpm2_eventlog ./t14_eventlog | grep "BOOT_SERVICES_DRIVER" | wc -l 7 This is essentially what me and Trammell Hudson has been thinking about. But I don't have any available machines to test this with, and I haven't gotten around to setting up a QEMU vm to test out this theory. https://github.com/Foxboron/sbctl/issues/85#issuecomment-886539689 https://github.com/Foxboron/sbctl/issues/85#issuecomment-886...
    - g_p 5y ago
      Good idea RE the TPM event log - that should show the definitive perceived hash of the option ROM. Will need to see if I have any computers that require an Option ROM - somehow I suspect shipped-with-Linux Dell XPS laptops aren't going to be good test candidates.
- blibble 5y ago
  I completely replace the entire set of secure boot keys with my own (no MS keys at all) for my desktop PC I had to sign the graphics card option ROM digest myself (which was a pain) however for my Thinkpad none of this was necessary as the firmware was stored inside the UEFI image