5 ms·

While it is certainly an interesting bug, I kinda feel that the title is click bait? Because this `cryptsetup luksSuspend` from what I understood is not really

by kokada 3mo ago

While it is certainly an interesting bug, I kinda feel that the title is click bait? Because this `cryptsetup luksSuspend` from what I understood is not really officially supported but an extension done in Debian, so if anything this regression only affected Debian? I am not sure if you can blame the kernel for something that is not supported or even widely tested. I still find this impressive, and it is nice that we now have a test (NixOSTests BTW are awesome, I agree with OP) to avoid this regression from coming back. But from the title it seems to be a widespread issue, not something that affects only one Distro.

IngoBlechschmid 3mo ago
Sorry, aimed for a technically precise title and didn't want to bait clicks. Yes, this does not affect people on stock configurations for the plain reason that they wouldn't expect the volume key to be safe during suspend anyway. Debian's solution was ported to several (most?) other distributions and I guess quite a few people maintained private ports. The thread-keyring(7) manpage promises: "A thread keyring is destroyed when the thread that refers to it terminates." For their key upload (from userspace to kernelspace) mechanism, the cryptsetup project relied on this property; but kernel 6.9 introduced a regression invalidating this property.
- kokada 3mo ago
  Thanks for the explanation, I am really not that familiar with `cryptsetup luksSuspend` and it is the first time I ever heard it exists. Like other people in this thread I first got confused "wait, how would this work since if you cleanup the keys from the disk during suspend you couldn't access the disk anymore after resuming", but after reading your thread in Mastodon plus other comments here it eventually became clear that this is a special case that you need both the correct patches plus the correct setup to use `cryptsetup luksSuspend` in place of the normal suspend. Can I ask one question? Why not use hibernation at that point? The reason I generally suspend to RAM is exactly because my password is long and annoying to type enough that if I know I am going to use the device soon I prefer to suspend instead of hibernation. Yes, technically resuming from suspend is faster, but it is also less secure (there are other interesting things in memory besides the LUKS keys) and also it uses more power.
  - cyphar 3mo ago
    > Can I ask one question? Why not use hibernation at that point? Not GP but hibernation is completely disabled for lockdown kernels[1], which is always enabled when booting under secure boot for kernels trusted by the Microsoft secure boot keys (it is considered a requirement to get you shim signed by rhboot[2] as it is believed that Microsoft considers it a hard requirement, as otherwise you could chain-load a patched version of Windows under secure boot). This doesn't matter for custom kernels but most official distro kernels are built this way to be signed, as otherwise they won't Just Work (TM) on modern laptops. If you disable secure boot then hibernation works again, though I must admit I'm a little surprised how many people seem to disable secure boot. [1]: https://www.man7.org/linux/man-pages/man7/kernel_lockdown.7.html https://www.man7.org/linux/man-pages/man7/kernel_lockdown.7.... [2]: https://github.com/rhboot/shim-review#how-does-your-signed-kernel-enforce-lockdown-when-your-system-runs-with-secure-boot-enabled https://github.com/rhboot/shim-review#how-does-your-signed-k...
    - assbuttbuttass 3mo ago
      > I must admit I'm a little surprised how many people seem to disable secure boot. To me, secure boot is the setting that I need to remember to turn off before installing the OS, but I would be willing to be convinced otherwise
      - cyphar 3mo ago
        To be fair the security argument for secure boot is weakened by the fact that everything is signed by the same set of trusted keys when using the default Microsoft trust root, but on paper it does protect against certain kinds of attacks. (In theory, distros could use UEFI setup mode to only trust their own keys but this causes issues with signed firmware and there have been cases of bricked devices.) Even if you use full disk encryption, without secure boot someone can replace your kernel (or bootloader to inject a bad kernel) with one that is backdoored without you noticing. So someone only needs temporary access to your powered off laptop to gain access to your data once you use it again. I've had my devices taken away from me at airports and I know people who have had their laptops mysteriously missing screws when travelling overseas, so this is not an entirely hypothetical problem. Of course, the fact that hibernation doesn't work on Linux is a negative from a practical security perspective, and so stuff like luksSuspend on suspend end up being quite important. And trusting the Microsoft keys is a little concerning if you're worried about state actors. If you use TPM-backed keys with tools like systemd-pcrlock you can get some similar (and arguably nicer) protections but in practice nobody locks to enough PCRs to provide more protection than you would get if you also enabled secure boot.
NooneAtAll3 3mo ago
what debian version first shipped 6.9?
- tremon 3mo ago
  Only the current stable (13/trixie); bookworm shipped with 6.1 as the main kernel (with 6.12 available in backports).
deleted 3mo ago
[deleted]
nicce 3mo ago
Hmm, the subcommand is in the official cryptsetup repository and the description matches? https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/man/cryptsetup-luksSuspend.8.adoc https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/man/cry...
michaelmrose 3mo ago
I've used this feature on arch its available on bog standard luks but as far as I know it's not used by default when you suspend. You are thinking of the machinery to actually actuate suspend to ram after a luks suspend in a way that is actually useful which was first a Debian targeted thing then arch and used by default by neither.
cyphar 3mo ago
I'm confused why you're saying this is a Debian-specific thing -- luksSuspend is upstream and was added back in 2009[1] in release v1.1.0[2]. I've used it (though somewhat sparingly) on Arch and openSUSE in the past and it definitely exists on non-Debian distributions. Maybe you're thinking of the automatic integration with system suspend? If so, that's kind of besides the point -- luksSuspend documents itself as clearing the keys from system memory, which stopped happening in Linux 6.9 due to the referenced refactor patch. Though it should be noted that it seems that this is actually a bug in cryptsetup in that it was depending on very specific lifetime behaviour of kernel keyring keys, when it arguably should've been more explicitly cleared by userspace[3]. [1]: https://gitlab.com/cryptsetup/cryptsetup/-/commit/3cea5dcc7b80571d705f922ac112b0577b4fae47 https://gitlab.com/cryptsetup/cryptsetup/-/commit/3cea5dcc7b... [2]: https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/docs/v1.1.0-ReleaseNotes#L44 https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/docs/v1... [3]: https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/937 https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/93...

by kokada 3mo ago

IngoBlechschmid 3mo ago

Sorry, aimed for a technically precise title and didn't want to bait clicks. Yes, this does not affect people on stock configurations for the plain reason that they wouldn't expect the volume key to be safe during suspend anyway. Debian's solution was ported to several (most?) other distributions and I guess quite a few people maintained private ports. The thread-keyring(7) manpage promises: "A thread keyring is destroyed when the thread that refers to it terminates." For their key upload (from userspace to kernelspace) mechanism, the cryptsetup project relied on this property; but kernel 6.9 introduced a regression invalidating this property.

kokada 3mo ago
Thanks for the explanation, I am really not that familiar with `cryptsetup luksSuspend` and it is the first time I ever heard it exists. Like other people in this thread I first got confused "wait, how would this work since if you cleanup the keys from the disk during suspend you couldn't access the disk anymore after resuming", but after reading your thread in Mastodon plus other comments here it eventually became clear that this is a special case that you need both the correct patches plus the correct setup to use `cryptsetup luksSuspend` in place of the normal suspend. Can I ask one question? Why not use hibernation at that point? The reason I generally suspend to RAM is exactly because my password is long and annoying to type enough that if I know I am going to use the device soon I prefer to suspend instead of hibernation. Yes, technically resuming from suspend is faster, but it is also less secure (there are other interesting things in memory besides the LUKS keys) and also it uses more power.
- cyphar 3mo ago
  > Can I ask one question? Why not use hibernation at that point? Not GP but hibernation is completely disabled for lockdown kernels[1], which is always enabled when booting under secure boot for kernels trusted by the Microsoft secure boot keys (it is considered a requirement to get you shim signed by rhboot[2] as it is believed that Microsoft considers it a hard requirement, as otherwise you could chain-load a patched version of Windows under secure boot). This doesn't matter for custom kernels but most official distro kernels are built this way to be signed, as otherwise they won't Just Work (TM) on modern laptops. If you disable secure boot then hibernation works again, though I must admit I'm a little surprised how many people seem to disable secure boot. [1]: https://www.man7.org/linux/man-pages/man7/kernel_lockdown.7.html https://www.man7.org/linux/man-pages/man7/kernel_lockdown.7.... [2]: https://github.com/rhboot/shim-review#how-does-your-signed-kernel-enforce-lockdown-when-your-system-runs-with-secure-boot-enabled https://github.com/rhboot/shim-review#how-does-your-signed-k...
  - assbuttbuttass 3mo ago
    > I must admit I'm a little surprised how many people seem to disable secure boot. To me, secure boot is the setting that I need to remember to turn off before installing the OS, but I would be willing to be convinced otherwise
    - cyphar 3mo ago
      To be fair the security argument for secure boot is weakened by the fact that everything is signed by the same set of trusted keys when using the default Microsoft trust root, but on paper it does protect against certain kinds of attacks. (In theory, distros could use UEFI setup mode to only trust their own keys but this causes issues with signed firmware and there have been cases of bricked devices.) Even if you use full disk encryption, without secure boot someone can replace your kernel (or bootloader to inject a bad kernel) with one that is backdoored without you noticing. So someone only needs temporary access to your powered off laptop to gain access to your data once you use it again. I've had my devices taken away from me at airports and I know people who have had their laptops mysteriously missing screws when travelling overseas, so this is not an entirely hypothetical problem. Of course, the fact that hibernation doesn't work on Linux is a negative from a practical security perspective, and so stuff like luksSuspend on suspend end up being quite important. And trusting the Microsoft keys is a little concerning if you're worried about state actors. If you use TPM-backed keys with tools like systemd-pcrlock you can get some similar (and arguably nicer) protections but in practice nobody locks to enough PCRs to provide more protection than you would get if you also enabled secure boot.

NooneAtAll3 3mo ago

what debian version first shipped 6.9?

tremon 3mo ago
Only the current stable (13/trixie); bookworm shipped with 6.1 as the main kernel (with 6.12 available in backports).

deleted 3mo ago

[deleted]

nicce 3mo ago

Hmm, the subcommand is in the official cryptsetup repository and the description matches? https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/man/cryptsetup-luksSuspend.8.adoc https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/man/cry...

michaelmrose 3mo ago

I've used this feature on arch its available on bog standard luks but as far as I know it's not used by default when you suspend. You are thinking of the machinery to actually actuate suspend to ram after a luks suspend in a way that is actually useful which was first a Debian targeted thing then arch and used by default by neither.

cyphar 3mo ago

I'm confused why you're saying this is a Debian-specific thing -- luksSuspend is upstream and was added back in 2009[1] in release v1.1.0[2]. I've used it (though somewhat sparingly) on Arch and openSUSE in the past and it definitely exists on non-Debian distributions. Maybe you're thinking of the automatic integration with system suspend? If so, that's kind of besides the point -- luksSuspend documents itself as clearing the keys from system memory, which stopped happening in Linux 6.9 due to the referenced refactor patch. Though it should be noted that it seems that this is actually a bug in cryptsetup in that it was depending on very specific lifetime behaviour of kernel keyring keys, when it arguably should've been more explicitly cleared by userspace[3]. [1]: https://gitlab.com/cryptsetup/cryptsetup/-/commit/3cea5dcc7b80571d705f922ac112b0577b4fae47 https://gitlab.com/cryptsetup/cryptsetup/-/commit/3cea5dcc7b... [2]: https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/docs/v1.1.0-ReleaseNotes#L44 https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/docs/v1... [3]: https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/937 https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/93...