RFC: Print a loud warning if wiping the volume key is impossible

Ingo Blechschmidtrequested to merge
iblech/cryptsetup:patch-leak-detection into main

The kernel codepath triggered by cryptsetup luksSuspend only wipes the volume key in dm-crypt's own data structures. Copies of the volume key in kernel keyrings are not wiped. This happens in the following three situations:

  1. The user purposefully put a copy into a keyring of their own.
  2. A long-running program used libcryptsetup to open a volume and did not yet close it.
  3. A volume was opened with the oneshot cryptsetup luksOpen command on a kernel containing the (to my mind) extremely scary bug described at https://lore.kernel.org/all/ajKwRtP8izwRsMmv@quasitopos/. At the time of writing, this is every kernel starting with version 6.9 (released in May 2024).

In Situation 1, it's probably not a surprise that cryptsetup luksSuspend fails to wipe the volume key from memory.

In Situation 2, it is perhaps more surprising. (But understandable from the code: For passing the volume key to the kernel, we use our thread keyring, and we purge this keyring only on failure. On successful open, the key remains in the keyring, and we trust that the keyring will be garbage collected by the kernel on process exit.)

In Situation 3, one could say it's quite dramatic. I believe that many people have the expectation that a simple cryptsetup luksOpen followed by cryptsetup luksSuspend should work, i.e. successfully wipe the volume key from memory. But this is only true on pre-v6.9 kernels. (For a discussion how to reliably reproduce this bug, see issue #993 (closed).)

As a concrete consequence, Debian's cryptsetup-suspend (which was then adopted by several other Linux distributions) currently silently fails to protect the volume during suspend.

With this merge request, (lib)cryptsetup tries to print a warning when wiping the volume key is impossible, instead of failing silently.

This pull request is not yet polished. In particular, I haven't thought about the OPAL situation at all. But before I invest more work, I'd like to gather your opinion: Would something like this be considered worthwhile?

Edited by Ingo Blechschmidt

Merge request reports