From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1n4tGH-00044l-2M for mharc-grub-devel@gnu.org; Tue, 04 Jan 2022 18:30:40 -0500 Received: from eggs.gnu.org ([209.51.188.92]:51122) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n4tGC-00042Z-IL for grub-devel@gnu.org; Tue, 04 Jan 2022 18:30:33 -0500 Received: from [2607:f8b0:4864:20::b2e] (port=35509 helo=mail-yb1-xb2e.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n4tGA-0005bO-TA for grub-devel@gnu.org; Tue, 04 Jan 2022 18:30:32 -0500 Received: by mail-yb1-xb2e.google.com with SMTP id j83so93985833ybg.2 for ; Tue, 04 Jan 2022 15:30:30 -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=5DseIDAhHIUvaiJFT/DhqflkivWbJJhnMmqOVzsJICo=; b=BmBAm7/zdRwsd/aXjltglrNg6UIbdOanBv4QzdLm4mKlZf2r4HGzmeNT9dyGqDmWfV nZu4tDtvkoTobnFM7ilLBiuw76IArRCusZlFthhUMDVr82+eqmPWEHDwo4mj6k/VMiF3 LNCb24EBsLqlUSdoGhAx8HLAyrlOvnt03Nzzr2BpZFBvvWlnGF2JO/+cIp65PtLzgjZA 5k/bbIiG5wC9DSUkH7oaCV6ZQm6ObG9JszeIz/F1mBifsT4ORbQ1KD7NuR4qtxjXrQgu 4wi/dx82zSYFqe20CMBiSdKnW4IPmo4HzekNVpWOPG7Kq0II5TUcA97V7EIlU8if2eUE VtwA== 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=5DseIDAhHIUvaiJFT/DhqflkivWbJJhnMmqOVzsJICo=; b=hJLsFj1AkKz1iuEVlnHcIwDhFFX1JuRLrMRccgDvxMRdi9hkASdbbjlbC7NiunZ9Uv CDdjtGYBHrfoGFzcDuwE6COrqSEIyweTjsXaiS63FUv4ELGpcFSxPg+lElzU5w9p357n h+hNcBMKya7J3r48N5vprdGywWkY79BEsRsHPc84N32c3uSOqOsXsaq9eifc9HVntySG M8EtFc4gsOroqMTSOeDuPoNwEq27IKXMjPERQyzkrSl7+8OnNQdFzNAAXoWN4tI5EgHr p+B0d1/zxJ7eflb+5ApCwX3nibQX2BsdZGWonQtvIeP+TO3YRNI+CQN04hkrDxUe/i4U z0uQ== X-Gm-Message-State: AOAM533qn7YIYEMHAMPIIxftiMQoA9lDQtAhz6MsgbShMazjtBcS6oOg cQRkHaY7aLOHni4qaaKCggai8TGoeQ/TmOg0jaI= X-Google-Smtp-Source: ABdhPJzshQ6BdbylAly8fvOHxSEG1/RQl909JjClfjTEBCiy5/1DmPvYJtfn+lCkw3cRNCemo+vRH59DoVmgzOgaZeg= X-Received: by 2002:a25:4002:: with SMTP id n2mr19679569yba.547.1641339029903; Tue, 04 Jan 2022 15:30:29 -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:30:19 +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="000000000000d55e1405d4ca05af" X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::b2e (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::b2e; envelope-from=reagentoo@gmail.com; helo=mail-yb1-xb2e.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:30:34 -0000 --000000000000d55e1405d4ca05af 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 01:57, Dmitry : > > > =D1=81=D1=80, 5 =D1=8F=D0=BD=D0=B2. 2022 =D0=B3. =D0=B2 01:07, Glenn Wash= burn : > >> 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 > 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. --000000000000d55e1405d4ca05af 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 01:57, Dmitry <reagentoo@gmail.com>:


=D1=81=D1=80, 5 =D1=8F= =D0=BD=D0=B2. 2022 =D0=B3. =D0=B2 01:07, Glenn Washburn <development@efficientek.c= om>:
On T= ue, 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
reflect the essence of this structure, = but further implementation the code will
not be pretty in this ca= se.

I still suggest expanding the number of parameters for the recov= er_key function
and use grub_disk_t to pass the header from the u= ser directly.

Although in= general I'm quite satisfied with the current patch set. It suits my
requirements. Maybe disk may be really useless<= /span> and I overdid it.. It will only
remain to add the m= aster key parameter in the future.
=C2=A0
--000000000000d55e1405d4ca05af--