From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1n4tZu-0006sJ-2R for mharc-grub-devel@gnu.org; Tue, 04 Jan 2022 18:50:54 -0500 Received: from eggs.gnu.org ([209.51.188.92]:54202) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n4tZr-0006sA-Ud for grub-devel@gnu.org; Tue, 04 Jan 2022 18:50:51 -0500 Received: from [2607:f8b0:4864:20::b33] (port=37395 helo=mail-yb1-xb33.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n4tZo-0001Z2-Gb for grub-devel@gnu.org; Tue, 04 Jan 2022 18:50:50 -0500 Received: by mail-yb1-xb33.google.com with SMTP id e202so69991610ybf.4 for ; Tue, 04 Jan 2022 15:50:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KBvJjw/YH6eKtoJYMPulgBTzXaqaaJLHpLCHHE/k9sA=; b=WO/JrA8ZEZeckjNfO4/j2HrHe4e8vC++zUrntsCAf8shNAIcC6c4NLGyDODbNTvexM U1BJGyQkHXAGoYFxEhKmoIdTBrT50lR1NtRUnvoUTWPUIG+e03UPzzwJqfOER6mRRu7k 3c+rMgXU30pW53FURo68Hj9rSo8oq1TT8F3vXVWXIjjUGWuOYArqiIBslJhbRk3LA9D4 MUGt8v1tPstsG1vcpWHyc/nEEHQKXBQmJdj5WvTF8WcRR6+M1zU42ywy10yWWEsdn/J+ qmI+Mgn4ZvhXwBOjdb/PQe34rxdNex2iVa7c1BsLavOdTgVI0VFS8G06JhlTUs+36iGj f1tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KBvJjw/YH6eKtoJYMPulgBTzXaqaaJLHpLCHHE/k9sA=; b=tZlBsuPNtI5m1rpxYLTnWhsN/KHVeI+r9tPywhMKtUnfH0/Wv1e5OJtdVyycOjBrva ammcDQIJTFCQamF246AMRRhhWbhc3Wf6JnN8vIVGZ8G/dLzKweXKD+LbUJxs9JzT07gG n9M/NujeqSnil9cRCqG9KzxIuAfSy5m9+Il+11Tg+xUey0BPR5VmApINzuwHZYhGw2ny jOstc9MVQQNFMnt38+XZvMF4dHi46h1E+D9e3h+nuQJIBrl73ftYxT4XDAR34w509JbC SPdf+2iwNuh2G9YansAnvnC5aJPFQcl1kFHiwlPaL12Yvr/aCAUJr5upWjloL7lZYHFS jUnw== X-Gm-Message-State: AOAM530C/vfvfiJ4Nn1mcHOKFIuHpbdERyJszugqGOdHuoGB8B2KZ+6K ABdzaIyS4hswZ7eNY9wUz3YPvZZ7lpIudM7OJAg= X-Google-Smtp-Source: ABdhPJz3jKaxMKR/J+L1V7YmER2CUHUKTV6TwQfLftCSggXUkuetw0OU8yFoMdff+WtSiNLAQijCMkSVq7GUkgaomP4= X-Received: by 2002:a25:4002:: with SMTP id n2mr19762068yba.547.1641340247483; Tue, 04 Jan 2022 15:50:47 -0800 (PST) MIME-Version: 1.0 References: <20220104154222.142bd77e@crass-HP-ZBook-15-G2> <20220104160656.18fbd917@crass-HP-ZBook-15-G2> In-Reply-To: From: Dmitry Date: Wed, 5 Jan 2022 02:50:36 +0300 Message-ID: Subject: Re: [PATCH v8 3/7] cryptodisk: enable the backends to implement detached headers To: Glenn Washburn Cc: Daniel Kiper , grub-devel , "Denis 'GNUtoo' Carikli" , Patrick Steinhardt , John Lane Content-Type: multipart/alternative; boundary="000000000000682a0405d4ca4ef8" X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::b33 (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::b33; envelope-from=reagentoo@gmail.com; helo=mail-yb1-xb33.google.com X-Spam_score_int: 6 X-Spam_score: 0.6 X-Spam_bar: / X-Spam_report: (0.6 / 5.0 requ) DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2022 23:50:52 -0000 --000000000000682a0405d4ca4ef8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D1=81=D1=80, 5 =D1=8F=D0=BD=D0=B2. 2022 =D0=B3. =D0=B2 02:30, Dmitry : > > > =D1=81=D1=80, 5 =D1=8F=D0=BD=D0=B2. 2022 =D0=B3. =D0=B2 01:57, Dmitry : > >> >> >> =D1=81=D1=80, 5 =D1=8F=D0=BD=D0=B2. 2022 =D0=B3. =D0=B2 01:07, Glenn Was= hburn : >> >>> 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. Thi= s >> would >> > So, please ignore these statements. Looks like it's not valid. > reflect the essence of this structure, but further implementation the cod= e >> 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. > > --000000000000682a0405d4ca4ef8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
=D1=81=D1=80, 5 =D1=8F=D0=BD=D0=B2. 2= 022 =D0=B3. =D0=B2 02:30, Dmitry <reagentoo@gmail.com>:


=D1=81=D1=80, 5 =D1=8F= =D0=BD=D0=B2. 2022 =D0=B3. =D0=B2 01:57, Dmitry <reagentoo@gmail.com>:


=D1=81=D1=80, 5 =D1=8F=D0=BD=D0=B2. 2022 =D0=B3. =D0=B2 01:07, Gl= enn Washburn <development@efficientek.com>:
On Tue, 4 Jan 2022 15:42:22 -0600
Glenn Washburn <development@efficientek.com> wrote:

I'm generally very pro-flexibility, but I'm not sure I like this fr= om 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?
<= br>
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 sta= te 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 structu= re.
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 t= his structure. This would

So, please ignore these statements.<= /span> Looks like it= 's not valid.
=C2=A0
reflect the essence of this structure, but fu= rther 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 di= rectly.

Although in gener= al I'm quite satisfied with the current patch set. It suits my
requirements. Maybe disk may be really usel= ess and I overdid it.. It will only
remain t= o add the master key parameter in the future.
=C2=A0
--000000000000682a0405d4ca4ef8--