5 ms·

I wouldn't be surprised if 50% of Linux users already have Secure Boot disabled - and probably 98% of Linux users have the wherewithal to get into the BIOS and

I wouldn't be surprised if 50% of Linux users already have Secure Boot disabled - and probably 98% of Linux users have the wherewithal to get into the BIOS and disable it if they needed to. And doing so has negligible downsides, as almost nobody on Linux has been fool enough to make use of the TPM.

candiddevmike 4y ago
TPM support on Linux (for drive encryption) is getting better with tools like clevis. Additionally, systemd can do a ton of cool things with TPM, and projects like dm-verity can make linux's boot process more locked down than Windows. I personally will always use a passphrase for device encryption.
- Laaas 4y ago
  Passphrase + TPM is best.
cryptonector 4y ago
> [...] almost nobody on Linux has been fool enough to make use of the TPM. Can you elaborate as to what is foolish about using a TPM?
- ghostpepper 4y ago
  Not the OP but just anecdotally, last time I looked into enabling secure boot on my X1 Carbon there was an advisory from Lenovo that enrolling your own keys made it possible to brick the machine https://wiki.archlinux.org/title/Lenovo_ThinkPad_X1_Carbon_(Gen_7) https://wiki.archlinux.org/title/Lenovo_ThinkPad_X1_Carbon_(...
  - privacyking 4y ago
    That's only if you fail to enroll the Lenovo hardware firmware images
    - ghostpepper 4y ago
      Can you link to a doc explaining how to do that? I'm not even sure what it means to enrol a firmware image. I'd love to finally get this working.
      - LoganDark 4y ago
        I think they're referring to the BIOS itself, since even that needs to be signed and verified.
        mjg59 4y ago
        It does, but it's not signed with the UEFI Secure Boot keys (Boot Guard has its own mechanism that's burned into chipset fuses, you can't re-key it)
      - privacyking 4y ago
        https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Microsoft_Windows https://wiki.archlinux.org/title/Unified_Extensible_Firmware... It's referring to dual booting windows but the same principles apply.
  - mjg59 4y ago
    That's related to Secure Boot, not the TPM
- michaelt 4y ago
  In practice you have to enrol your own MOK if you want to use the nvidia drivers, or v4l2-loopback, or virtualbox, or a bunch of other things - so unlike on Windows, it doesn't give you any great OS integrity benefits. You want those modules signed by someone like Canonical, so you don't have to mess around with a MOK? If you use Ubuntu Core they'll be happy to - for about $100,000 per year per module. Automatically unlocking hard drive encryption is less secure than just typing in a password at boot. No OS-independent way of confirming the user's presence means it's less secure than a Yubikey. No iphone-style activation lock, so it's useless as a theft deterrent. No xbox-style main memory or system bus encryption, so no protection against evil maid attacks. Too slow for servers to offload SSL or disk encryption to - so all the important keys end up being held in memory anyway. The spec and interface are complicated as hell, so you know there's no chance this stuff is bug-free. You want a command line tool? We've got 99 command line tools. Literally. The foundation of its security is the code of your system's BIOS, which we all know is some of the shittiest code out there. So the TPM offers a hair-trigger system that'll destroy all your data if your BIOS vendor messes up and miscalculates a PCR value. The security benefits you get in return are pretty minor.
  - cryptonector 4y ago
    The MOK thing is secure boot, not TPM related. You can have arbitrarily complex TPM authorization policies for unlocking storage keys. You can have it be that the loaded firmwares and OS are trusted and (or or) you have to enter in a passphrase that only the TPM can verify, and/or you can have a recovery mechanism so that if some firmware got updated you could use a smartcard or whatever to authorize moving on anyways. So, while OSes that support TPMs for storage key recovery generally have -as you say- hair-trigger policies, that's not TPM's fault but the OS's, for they could develop much more interesting policies.
    - nextaccountic 4y ago
      How to do those things in Linux?
      - 4y ago
- hulitu 4y ago
  > Can you elaborate as to what is foolish about using a TPM? Another backdoored closed piece of hardware ?
JohnFen 4y ago
I keep it disabled on all my machines. I can secure my machine using whole disk encryption, and secure boot is just a royal pain in the butt. I recognize that I am decreasing my security a bit, but that tradeoff is worth it to me.
- hilbert42 4y ago
  "...secure boot is just a royal pain in the butt." Fully agree, when I first read the HN story headline my initial reaction was where can I get a copy for use on my own machines.
throwaway742 4y ago
Disabling it is always one of the first things I do with a new system even if it is running windows. It's probably not rational, but I hate the whole concept of a TPM.

candiddevmike 4y ago

TPM support on Linux (for drive encryption) is getting better with tools like clevis. Additionally, systemd can do a ton of cool things with TPM, and projects like dm-verity can make linux's boot process more locked down than Windows. I personally will always use a passphrase for device encryption.

Laaas 4y ago
Passphrase + TPM is best.

cryptonector 4y ago

> [...] almost nobody on Linux has been fool enough to make use of the TPM. Can you elaborate as to what is foolish about using a TPM?

ghostpepper 4y ago
Not the OP but just anecdotally, last time I looked into enabling secure boot on my X1 Carbon there was an advisory from Lenovo that enrolling your own keys made it possible to brick the machine https://wiki.archlinux.org/title/Lenovo_ThinkPad_X1_Carbon_(Gen_7) https://wiki.archlinux.org/title/Lenovo_ThinkPad_X1_Carbon_(...
- privacyking 4y ago
  That's only if you fail to enroll the Lenovo hardware firmware images
  - ghostpepper 4y ago
    Can you link to a doc explaining how to do that? I'm not even sure what it means to enrol a firmware image. I'd love to finally get this working.
    - LoganDark 4y ago
      I think they're referring to the BIOS itself, since even that needs to be signed and verified.
      - mjg59 4y ago
        It does, but it's not signed with the UEFI Secure Boot keys (Boot Guard has its own mechanism that's burned into chipset fuses, you can't re-key it)
    - privacyking 4y ago
      https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Microsoft_Windows https://wiki.archlinux.org/title/Unified_Extensible_Firmware... It's referring to dual booting windows but the same principles apply.
- mjg59 4y ago
  That's related to Secure Boot, not the TPM
michaelt 4y ago
In practice you have to enrol your own MOK if you want to use the nvidia drivers, or v4l2-loopback, or virtualbox, or a bunch of other things - so unlike on Windows, it doesn't give you any great OS integrity benefits. You want those modules signed by someone like Canonical, so you don't have to mess around with a MOK? If you use Ubuntu Core they'll be happy to - for about $100,000 per year per module. Automatically unlocking hard drive encryption is less secure than just typing in a password at boot. No OS-independent way of confirming the user's presence means it's less secure than a Yubikey. No iphone-style activation lock, so it's useless as a theft deterrent. No xbox-style main memory or system bus encryption, so no protection against evil maid attacks. Too slow for servers to offload SSL or disk encryption to - so all the important keys end up being held in memory anyway. The spec and interface are complicated as hell, so you know there's no chance this stuff is bug-free. You want a command line tool? We've got 99 command line tools. Literally. The foundation of its security is the code of your system's BIOS, which we all know is some of the shittiest code out there. So the TPM offers a hair-trigger system that'll destroy all your data if your BIOS vendor messes up and miscalculates a PCR value. The security benefits you get in return are pretty minor.
- cryptonector 4y ago
  The MOK thing is secure boot, not TPM related. You can have arbitrarily complex TPM authorization policies for unlocking storage keys. You can have it be that the loaded firmwares and OS are trusted and (or or) you have to enter in a passphrase that only the TPM can verify, and/or you can have a recovery mechanism so that if some firmware got updated you could use a smartcard or whatever to authorize moving on anyways. So, while OSes that support TPMs for storage key recovery generally have -as you say- hair-trigger policies, that's not TPM's fault but the OS's, for they could develop much more interesting policies.
  - nextaccountic 4y ago
    How to do those things in Linux?
    - 4y ago
hulitu 4y ago
> Can you elaborate as to what is foolish about using a TPM? Another backdoored closed piece of hardware ?

JohnFen 4y ago

I keep it disabled on all my machines. I can secure my machine using whole disk encryption, and secure boot is just a royal pain in the butt. I recognize that I am decreasing my security a bit, but that tradeoff is worth it to me.

hilbert42 4y ago
"...secure boot is just a royal pain in the butt." Fully agree, when I first read the HN story headline my initial reaction was where can I get a copy for use on my own machines.

throwaway742 4y ago

Disabling it is always one of the first things I do with a new system even if it is running windows. It's probably not rational, but I hate the whole concept of a TPM.