Re: Bug: luksClose search LUKS header but it is detached

[Milan Broz <gmazyland@gmail.com>]

On 10/08/2022 14:51, doffloster@gmail.com wrote:
> Hi Milan,
> 
> I appreciate your quick response.
> 
> Here is my reply:
> 
>> No, this is expected. But for close (deactivation) it proceeds even
>> if it does not find the detached header.
> 
> Why would cryptsetup seek the detached header in the device?
> Wouldn't it be better for cryptsetup to use the '--header' flag?

Kernel has no information that detached header was used, so userspace
always tries to initialize the context using header.

Close was, for a long time, an exception, the device was just teared down
without checking context.
But we already have use cases where we need full initialized context
even on close (check that header has correct UUID referenced in kernel etc).

That said, it should not scan for header if there is no space for
it (IOW data offset is 0 - there is no reserved space on data device
for header; only detached header exists; data device is fully used).
If this is happening, it is a bug. (I'll check it.)
  
>> The reason is that even close need some information from the header
>> (for example UUID).
> 
> Doesn't the linux kernel store this kind of information?

Yes, but it need to be compared against the header, not the kernel.
(Imagine that you need to check password before tearing down the device
- not the current situation, but we already have a need for it in the future).
  
>> Is there any functional problem with this or it just looks strange?
> 
> There isn't any issue.
> I just noticed an unexpected behavior and thought that I should report about it.

We can easily add option that will not check the header on close, but
if it is no real problem, I would better keep it as all actions basically
works the same.

Thanks,
Milan


> 
> Best regards,
> David.
> 
> 
> On Wed, Aug 10, 2022 at 9:58 AM Milan Broz <gmazyland@gmail.com> wrote:
>>
>> On 09/08/2022 23:53, doffloster@gmail.com wrote:
>>> Hi all,
>>>
>>> I noticed that cryptsetup LUKS extensions is searching for a LUKS
>>> header in the device.
>>> This is expected when the LUKS header should be in the device.
>>> But I used a detached LUKS header, so I wasn't expecting to see
>>> cryptsetup searching for the LUKS header in the device.
>>>
>>> You can see that in the log file "log.txt" - in the URL:
>>> https://drive.google.com/file/d/1DcrpklgE75oE5znAxHAlp9CPikkYbVq1/view?usp=sharing
>>>
>>> You may notice that I used a "--header" flag, but I also tried without
>>> it - still, cryptsetup behaved the same.
>>>
>>> The incriminating lines from the attached log are as follows:
>>
>> ...
>>> Do you consider it to be a bug?
>>
>> Hi,
>>
>> No, this is expected. But for close (deactivation) it proceeds even
>> if it does not find the detached header.
>>
>> The reason is that even close need some information from the header
>> (for example UUID).
>>
>> Is there any functional problem with this or it just looks strange?
>>
>> If it is problem, you can always use low-level access through
>> "dmsetup remove <device>" here, but it can keeps some underlying device
>> active (for LUKS2 this is used only for integrity protected devices).
>>
>> Milan
>>
>>