From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1nqHS0-0000RL-Th for mharc-grub-devel@gnu.org; Sun, 15 May 2022 12:50:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56888) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nqHS0-0000QH-2r for grub-devel@gnu.org; Sun, 15 May 2022 12:50:36 -0400 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:55699) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nqHRy-0002tf-9p for grub-devel@gnu.org; Sun, 15 May 2022 12:50:35 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id B564A320085B; Sun, 15 May 2022 12:50:32 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sun, 15 May 2022 12:50:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pks.im; h=cc:cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1652633432; x=1652719832; bh=zvFdmrhC/M g3KIMA6lcZkzP1LPb8f5CPdV2vLfjnf5Y=; b=o1AUT2bJqxLckLxedeOZTqQoPA 5hbnn8TvbsqHXLfPb+YfjvSZ2t54Fz6fDRW6CCGu+pyBhqAKzuir5GnDfQCPqf0J FIn5XLBy+VjqjhNQN8/0k9T/btTA9DoNRgEevEfMIhsX+gyQof5Rd8lqok5qxpoG wqzjElgAFEe+RlHBhYLzM5PA+dXuR2OinvpOrM2C/M24YHjHDVdSdYiUlyw0SftM IP6kP58dXRxxX9uQKW9JjZpv7QK6Q+DFgutoggxCpCJi7Ut31d6osCSq0zmYCbDk iUvNJr/51pyEYmJRT2Bv+GcGHmRJFsBRSMPIwTgcUbknvKb6miatT2alibtA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1652633432; x= 1652719832; bh=zvFdmrhC/Mg3KIMA6lcZkzP1LPb8f5CPdV2vLfjnf5Y=; b=D NYKvU00Z7zCw8bz22wBmHORvp2yeOl3OaW6QZhy8jXeiCx+Ag4H2lvbqOL8neADK WGmW5SCYhJFDVegXTUWD5NzsWkFuyR1boYQxNJbv7aaXoj5kWQnk0M5esRhhC3Xp ckPtUFiQSJTm2b8p+7IrDWPSqsREXbXWYoC0OL5+A5kUWsYg17bH3o5affmAL6nC Wn4LcSCTmFEIzqBpdV5ZfTt+p3ZUjAPjyk9eEGWw4uAR9tlp4guPOQAenVDRP/CK Q8uhwHmkNlhQbyy/NfC2j/pLer9gse6W2N9icJxW0hPeFic4TWUFzNt1S9jZmSr9 1qqhOSZkM4LO8OxFBPtqw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrheefgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtvdenucfhrhhomheprfgrthhr ihgtkhcuufhtvghinhhhrghrughtuceophhssehpkhhsrdhimheqnecuggftrfgrthhtvg hrnhepueektdevtdffveeljeetgfehheeigeekleduvdeffeeghefgledttdehjeelffet necuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomhepphhsse hpkhhsrdhimh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 15 May 2022 12:50:31 -0400 (EDT) Received: from localhost (xps [10.192.0.12]) by vm-mail.pks.im (OpenSMTPD) with ESMTPSA id da109c03 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 15 May 2022 16:50:30 +0000 (UTC) Date: Sun, 15 May 2022 18:50:29 +0200 From: Patrick Steinhardt To: Daniel Kiper Cc: Glenn Washburn , grub-devel@gnu.org, Denis 'GNUtoo' Carikli , John Lane Subject: Re: [PATCH 0/3] Cryptomount detached headers Message-ID: References: <20220513112412.5y2mhhmt3mmjpj57@tomti.i.net-space.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="85y38Ue8yE1U7XhQ" Content-Disposition: inline In-Reply-To: <20220513112412.5y2mhhmt3mmjpj57@tomti.i.net-space.pl> Received-SPF: pass client-ip=64.147.123.19; envelope-from=ps@pks.im; helo=wout3-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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: Sun, 15 May 2022 16:50:36 -0000 --85y38Ue8yE1U7XhQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 13, 2022 at 01:24:12PM +0200, Daniel Kiper wrote: > On Tue, May 10, 2022 at 11:53:06PM -0500, Glenn Washburn wrote: > > This patch series is, I believe, a better approach to supporting detach= ed > > headers for cryptomount and backends. This series will probably not app= ly > > cleanly without the changes from the recent series entitled "[PATCH 0/4] > > Cryptomount keyfile support". But its only because they touch code in t= he > > same vicinity, not because there's any real dependency. > > > > 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 inst= ances > > 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. It takes > > care of the case where there is already a previous read hook on the sou= rce > > device and will call that read hook after modifying the read buffer. I = don't > > believe this is strictly necessary currently because I don't think there > > ever is a read hook already set since the disk was just created with a > > grub_disk_open(). I'm not opposed to getting rid of this code. The one > > benefit I see if a bit of future proofing. >=20 > I would get rid of this code. The first question which comes to my mind > is: which hook has to process the data first? If we do not know potential > users of that "multi-hook" feature I would not introduce it to not > create a feeling the hook interface is well defined. So, at this point > I would suggest to stick with one hook only. >=20 > > The benefit of this approach is its simpler/less code and does not requ= ire > > the modification of backends, except to potentially cause a failure in > > scan() if the backend doesn't support the current implementation of det= ached > > 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. >=20 > I am OK with the idea though I would like to hear Patrick's opinion here. >=20 > Daniel It's rather intimate with how the backends are working right now, but has the big advantage that it's backend-agnostic except for GELI. I feel like the code warrants some more comments to explain what the underlying idea is, but overall I like it. Patrick --85y38Ue8yE1U7XhQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEF9hrgiFbCdvenl/rVbJhu7ckPpQFAmKBL1QACgkQVbJhu7ck PpQTWg//ZemDaHwTdczdYl26uMAS1sza1DEOSEAfOtysy8avnZGJdDrJfa0ytCNb 57i3OQcN0bDFdWzKTUdiaYAlEzBuKstECu2hVAgqRB1ECIbgErl1MATWGc3zherL hg4D1cSN3FcrI/LDw/pGoIbWpvBRiCdIhMs55aSWVoX1Ry/tWEExWv7ZYRV0cIWc JJQeRDxge9bzr87+dNFpzElIi3RVjopgcvt+JZnVtJPcn7shjTuDt4545+VDYykB zE0DFNlPXJUfDICq4SfZPtuQRVDnZXo5fNkY+sb5QdlMqfr0byZ7InndAMHoeugn pegJiySDfPQNWor0SvTOg+LuPP4JetmLenec9ifbw+U7jcaP1QjClfL/SW891KjO lfJyyHwvdQVbIti8QlymwnfZfJOEw6aAHWo3Zdh2OPpDr4jrm7PVxaL9s6VcBYc5 RNBB8gyXtCnWaiWs93OXzUMgNmN5dcDUX59Dq18w7F957ZgW35P0DitHaa0pgAOQ 9uLypjJIIb/R3Cw+WhbwOESotLLGZInARlRlPqpXj16vlKvkAmrIh504MHAQxjcL kRBJ+zbPg9ACN3dXCqS2LO+vRGS6pQGqY2LBdKwXfSF1nS6tg+1ldDrETEvy98RN 9Ce4GgVWN/uY98YxzLJlbc702h8iOIv0m7QVrYXHEe92O3QmCRU= =Kw+7 -----END PGP SIGNATURE----- --85y38Ue8yE1U7XhQ--