4 ms·
> Hibernate is less interesting, and apparently unsupported using secure boot anyway. That's not the case. I have a similar setup to yours (/ on ext4 with sepa
by vladvasiliu 4y ago
> Hibernate is less interesting, and apparently unsupported using secure boot anyway.
That's not the case. I have a similar setup to yours (/ on ext4 with separate swap, on LVM on LUKS, separate /efi) and my box hibernates just fine with secure boot and auto-unlock via TPM.
The difference with your setup is I don't use grub, but have the UEFI load a signed unified kernel image directly. Since this works so well, I never had a reason to mess around with yet another moving piece (grub or other bootloader).
As another commenter said, I haven't attempted to mess around with the MOK. I just replaced all the secure boot keys with my own, and I've also signed MS's Windows key (but not the 3rd party one) for my dual-boot needs.
---
For specifics: This is an up-to-date Arch Linux install, running on an HP EliteBook 840 G8 (11th gen intel). I know Debian may have older components than arch, but this setup has been working for more than a year now.
IIRC, the most significant change was brought by systemd 251 which started supporting auto-unlocking LUKS with the TPM. Before that, on an older computer with the same general setup, hibernation worked well, too. I just needed to input the unlock password (which I was too lazy to do, so I just used my yubikey - see https://github.com/agherzan/yubikey-full-disk-encryption https://github.com/agherzan/yubikey-full-disk-encryption).
- teo_zero 4y agoFascinating! How do you sign your kernel every time you recompile it? Do you need to store a new key into the UEFI every time?
- vladvasiliu 4y agoI use sbupdate [0] to build the unified kernel image and to sign it with my keys. It's run by a hook in the arch's package manager whenever the kernel, the initrd or the firmware images change. I saw the other day that systemd recently got an utility to do this, but I've never looked into that. sbupdate has been working fine for me for several years now. It doesn't store a new key in the uefi, it signs the new image with the key that uefi already knows about. See [1] for the whole setup and [2] for the signing part specifically. [0] https://github.com/andreyv/sbupdate https://github.com/andreyv/sbupdate [1] https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_your_own_keys https://wiki.archlinux.org/title/Unified_Extensible_Firmware... [2] https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Fully_automated_unified_kernel_generation_and_signing_with_sbupdate https://wiki.archlinux.org/title/Unified_Extensible_Firmware...
- nextaccountic 4y agoWhat's the point of auto-unlocking using the TPM? Does this mean people may be able to access your data without a password?
- vladvasiliu 4y agoThe point is that the PC boots up fully unattended. People could access my data without a password if they stole my machine and somehow managed to log in to it, say through a bug in the desktop manager on the login process. The LUKS key is in memory, so I guess if they can somehow read that, they could also access the drive. But I figure the convenience is worth it, I don't expect to be a high-level target for this. And if I were, the 5$ wrench attack would probably work better. If they stole the hard drive, they wouldn't be able to access the data, the TPM wouldn't release the key.