From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1nzLUj-0004FQ-5Y for mharc-grub-devel@gnu.org; Thu, 09 Jun 2022 12:58:53 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50388) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nzLUh-0004CN-9U for grub-devel@gnu.org; Thu, 09 Jun 2022 12:58:51 -0400 Received: from dibed.net-space.pl ([84.10.22.86]:43453) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_3DES_EDE_CBC_SHA1:192) (Exim 4.90_1) (envelope-from ) id 1nzLUf-00080u-48 for grub-devel@gnu.org; Thu, 09 Jun 2022 12:58:50 -0400 Received: from router-fw.i.net-space.pl ([192.168.52.1]:41780 "EHLO tomti.i.net-space.pl") by router-fw-old.i.net-space.pl with ESMTP id S2145907AbiFIQ6b (ORCPT ); Thu, 9 Jun 2022 18:58:31 +0200 X-Comment: RFC 2476 MSA function at dibed.net-space.pl logged sender identity as: dkiper Date: Thu, 9 Jun 2022 18:58:29 +0200 From: Daniel Kiper To: Glenn Washburn Cc: grub-devel@gnu.org, Denis 'GNUtoo' Carikli , Patrick Steinhardt , John Lane Subject: Re: [PATCH v3 0/3] Cryptomount detached headers Message-ID: <20220609165829.viwr7r5hutqhozpy@tomti.i.net-space.pl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Received-SPF: pass client-ip=84.10.22.86; envelope-from=dkiper@net-space.pl; helo=dibed.net-space.pl X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham 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: Thu, 09 Jun 2022 16:58:51 -0000 On Wed, Jun 08, 2022 at 10:34:01AM -0500, Glenn Washburn wrote: > Updates since v2: > * Address uneeded ret variable pointed out by Patrick > * Rebased onto latest master with keyfile and security changes. I don't think > this actually changed these patches though. > > Conceptually the approach is different than the previous detach header > series because this one uses the disk objects read hook to hook reads to > the disk in scan() and recover_key() such that if there is an associated > header file, the hook will cause the read to return data from the header > file instead of from the source disk. > > For this the read hook implementation needed to be upgaded because prior > it didn't get the read buffer sent from the read caller and so could not > modify its contents. Patch #1 updates the hook accordingly and all instances > of its use, but doesn't functionally change how GRUB operates. > > The second patch adds the header option to cryptomount and the read hook > to the source disk during the scan() and recover_key() stages. > The benefit of this approach is its simpler/less code and does not require > the modification of backends, except to potentially cause a failure in > scan() if the backend doesn't support the current implementation of detached > headers, as with the GELI backend. This implementation requires that the > crypto volume header reside at the beginning of the volume. GELI has its > header at the end, which is why it can not currently be supported. In > theory, GELI could be supported if extra assumptions about its source > access pattern during scan() and recovery_key() were made. I don't use GELI, > no one seems to be asking for GELI detached headers, and I don't think that > GELI even support detached headers with the official tools. So for me, not > supporting crypto volumes with headers at the end of the disk is not a big > deal. With the patch series each backend gets the header file through cargs, > so it can implement detached headers by solely operating on that file instead > of the hooked source disk. In the the future, a flag can be added to the > cryptodisk_dev_t that backends can sent when registering to enabled/disable > the use of the read hook, if the backend needs to read from both the detached > header file and the source disk. > > Glenn > > Glenn Washburn (3): > disk: Allow read hook callback to take read buffer to potentially > modify it > cryptodisk: Add support for using detached header files > docs: Add documentation on detached header option to cryptomount For all the patches Reviewed-by: Daniel Kiper ... Big thank you for all working on this! Daniel