Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <f569a35a-bff9-9dbb-2ded-7e02ee060a9a@gmail.com>
Date:   Sat, 3 Jun 2023 11:22:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.11.0
Subject: Re: [PATCH 0/5] Support kdump with LUKS encryption by reusing LUKS
 volume key
Content-Language: en-US
To:     Eric Biggers <ebiggers@kernel.org>, Coiby Xu <coxu@redhat.com>
Cc:     kexec@lists.infradead.org, Baoquan He <bhe@redhat.com>,
        x86@kernel.org, dm-devel@redhat.com,
        Pingfan Liu <kernelfans@gmail.com>,
        linux-kernel@vger.kernel.org, Dave Hansen <dave.hansen@intel.com>,
        Kairui Song <ryncsn@gmail.com>,
        Jan Pazdziora <jpazdziora@redhat.com>,
        Thomas Staudt <tstaudt@de.ibm.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Dave Young <dyoung@redhat.com>
References: <20230601072444.2033855-1-coxu@redhat.com>
 <20230602213452.GC628@quark.localdomain>
From:   Milan Broz <gmazyland@gmail.com>
In-Reply-To: <20230602213452.GC628@quark.localdomain>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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