3 ms·

Have you got SecureBoot working well on Linux? My last try was with Fedora 34, and I had to manually reinitialize TPM with every kernel upgrade. One of the seri

Have you got SecureBoot working well on Linux? My last try was with Fedora 34, and I had to manually reinitialize TPM with every kernel upgrade. One of the serious issues that keeps me on Windows.

mjg59 3y ago
The TPM isn't involved in secure boot. Could you provide some more details about what went wrong?
- lostmsu 3y ago
  It is about full disk encryption with automatic unlock during boot. One needs to make TPM dependent on a successful secure boot to allow access to decryption. The boot completes no problem, but the TPM entry that controls access needs to be manually recreated with each new kernel update. See https://gist.github.com/jdoss/777e8b52c8d88eb87467935769c98a95#enroll-your-encrypted-volumes https://gist.github.com/jdoss/777e8b52c8d88eb87467935769c98a... , the bit "then auto volume decryption on your next reboot will fail". This makes sense.
  - mjg59 3y ago
    Using anything other than PCR 7 is going to make it very fragile, yes - I have no idea why that doc is recommending using PCR 4 as well.
    - lostmsu 3y ago
      To defend against an attacker with physical access to an offline machine you need to verify anything that the attacker can overwrite without the encryption key. Aren't bootloader and kernel on the writable unencrypted partition?
      - mjg59 3y ago
        If you have secure boot enabled, how does the attacker replace the kernel or bootloader?
        lostmsu 3y ago
        Pull the drive out, insert it into his machine, replace, then insert it back.
        mjg59 3y ago
        And now the signature doesn't match, so the system doesn't boot
        lostmsu 3y ago
        Which signature?
        mjg59 3y ago
        The signature that's validated by secure boot. If you don't have secure boot turned on then there's no point in verifying PCR 7, because all PCR 7 contains is the secure boot data.
alekq 3y ago
It is just SecureBoot which is officially supported by many mainstream distros. I unlock encrypted partitions with a passphrase, not TPM.
yrro 3y ago
Don't worry about it: Secure Boot is (currently) 100% pointless on Linux because the initrd is not authenticated. Once the work described at https://lwn.net/Articles/918909/ https://lwn.net/Articles/918909/ this will change, and , and kernel updates should no longer require will (hopefully?) no longer require re-initializing the TPM.
- patrakov 3y ago
  Well, all my machines use Arch Linux with custom Secure Boot keys and unified kernel images (essentially, the kernel, the initrd, the command line, and the splash screen fused into one EFI executable and signed as a whole). So on my machines, the initrd is definitely verified. Thanks to Foxboron who made this easy with sbctl. An entirely different matter is that the default Microsoft keys allow running all other distros, with their GRUB which allows to load initrds without authentication - which would allow evil-made style attacks by replacing the whole boot chain and the kernel. So in my world, all builds of Shim and GRUB are malware, and keys that allow booting them are not allowed in the DB.

Have you got SecureBoot working well on Linux? My last try was with Fedora 34, and I had to manually reinitialize TPM with every kernel upgrade. One of the serious issues that keeps me on Windows.

mjg59 3y ago

The TPM isn't involved in secure boot. Could you provide some more details about what went wrong?

lostmsu 3y ago
It is about full disk encryption with automatic unlock during boot. One needs to make TPM dependent on a successful secure boot to allow access to decryption. The boot completes no problem, but the TPM entry that controls access needs to be manually recreated with each new kernel update. See https://gist.github.com/jdoss/777e8b52c8d88eb87467935769c98a95#enroll-your-encrypted-volumes https://gist.github.com/jdoss/777e8b52c8d88eb87467935769c98a... , the bit "then auto volume decryption on your next reboot will fail". This makes sense.
- mjg59 3y ago
  Using anything other than PCR 7 is going to make it very fragile, yes - I have no idea why that doc is recommending using PCR 4 as well.
  - lostmsu 3y ago
    To defend against an attacker with physical access to an offline machine you need to verify anything that the attacker can overwrite without the encryption key. Aren't bootloader and kernel on the writable unencrypted partition?
    - mjg59 3y ago
      If you have secure boot enabled, how does the attacker replace the kernel or bootloader?
      - lostmsu 3y ago
        Pull the drive out, insert it into his machine, replace, then insert it back.
        mjg59 3y ago
        And now the signature doesn't match, so the system doesn't boot
        lostmsu 3y ago
        Which signature?
        mjg59 3y ago
        The signature that's validated by secure boot. If you don't have secure boot turned on then there's no point in verifying PCR 7, because all PCR 7 contains is the secure boot data.

alekq 3y ago

It is just SecureBoot which is officially supported by many mainstream distros. I unlock encrypted partitions with a passphrase, not TPM.

yrro 3y ago

Don't worry about it: Secure Boot is (currently) 100% pointless on Linux because the initrd is not authenticated. Once the work described at https://lwn.net/Articles/918909/ https://lwn.net/Articles/918909/ this will change, and , and kernel updates should no longer require will (hopefully?) no longer require re-initializing the TPM.

patrakov 3y ago
Well, all my machines use Arch Linux with custom Secure Boot keys and unified kernel images (essentially, the kernel, the initrd, the command line, and the splash screen fused into one EFI executable and signed as a whole). So on my machines, the initrd is definitely verified. Thanks to Foxboron who made this easy with sbctl. An entirely different matter is that the default Microsoft keys allow running all other distros, with their GRUB which allows to load initrds without authentication - which would allow evil-made style attacks by replacing the whole boot chain and the kernel. So in my world, all builds of Shim and GRUB are malware, and keys that allow booting them are not allowed in the DB.