lkml.org 
[lkml]   [2023]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 0/5] Support kdump with LUKS encryption by reusing LUKS volume key
From
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

\
 
 \ /
  Last update: 2023-06-03 11:24    [W:0.218 / U:2.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site