Messages in this thread | | | Date | Sat, 3 Jun 2023 11:22:52 +0200 | Subject | Re: [PATCH 0/5] Support kdump with LUKS encryption by reusing LUKS volume key | From | Milan Broz <> |
| |
On 6/2/23 23:34, Eric Biggers wrote: > On Thu, Jun 01, 2023 at 03:24:39PM +0800, Coiby Xu wrote: >> [PATCH 0/5] Support kdump with LUKS encryption by reusing LUKS volume key > > The kernel has no concept of LUKS at all. It provides dm-crypt, which LUKS > happens to use. But LUKS is a userspace concept. > > This is a kernel patchset, so why does it make sense for it to be talking about > LUKS at all? Perhaps you mean dm-crypt?
Exactly.
I had the same comment almost a year ago... and it still applies: https://lore.kernel.org/all/c857dcf8-024e-ab8a-fd26-295ce2e0ae41@gmail.com/
Anyway, please fix the naming before this patchset can be read or reviewed!
LUKS is user-space key management only (on-disk metadata); the kernel has no idea how the key is derived or what LUKS is - dm-crypt only knows the key (either through keyring or directly in the mapping table).
Polluting kernel namespace with "luks" names variables is wrong - dm-crypt is used in many other mappings (plain, bitlocker, veracrypt, ...) Just use the dm-crypt key, do not reference LUKS at all.
Milan
| |