[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v8 3/7] cryptodisk: enable the backends to implement detached

From: Dmitry
Subject: Re: [PATCH v8 3/7] cryptodisk: enable the backends to implement detached headers
Date: Wed, 5 Jan 2022 02:50:36 +0300

ср, 5 янв. 2022 г. в 02:30, Dmitry <>:

ср, 5 янв. 2022 г. в 01:57, Dmitry <>:

ср, 5 янв. 2022 г. в 01:07, Glenn Washburn <>:
On Tue, 4 Jan 2022 15:42:22 -0600
Glenn Washburn <> wrote:

I'm generally very pro-flexibility, but I'm not sure I like this from a
user perspective. For the common case, which is detached headers in a
file, this will cause the user to do more work (create a loopback
device of the file). What's a reasonable scenario where a user would
want the detached header on a device as opposed to a file system? Am I
correct in thinking that you use such functionality?

Actually no, I only use a file for the external header, not a disk.
I have now looked at the patches again and will try to state my point of view in
more detail:

I don't think the hdr_file field as it stands in the patch set is relevant. I mean
the hdr_file field of type grub_file_t in the grub_cryptomount_args structure.
Even the grub_disk_t type may not be relevant here. You could only pass
a header file name or a disk name (as char*) through this structure. This would

So, please ignore these statements. Looks like it's not valid.
reflect the essence of this structure, but further implementation the code will
not be pretty in this case.

I still suggest expanding the number of parameters for the recover_key function
and use grub_disk_t to pass the header from the user directly.

Although in general I'm quite satisfied with the current patch set. It suits my
requirements. Maybe disk may be really useless and I overdid it.. It will only
remain to add the master key parameter in the future.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]