From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1ns7FC-0006k9-W2 for mharc-grub-devel@gnu.org; Fri, 20 May 2022 14:20:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42056) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ns7F9-0006ia-6D for grub-devel@gnu.org; Fri, 20 May 2022 14:20:56 -0400 Received: from jpoiret.xyz ([206.189.101.64]:35304) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ns7F5-0007Ux-Ol for grub-devel@gnu.org; Fri, 20 May 2022 14:20:54 -0400 Received: from authenticated-user (jpoiret.xyz [206.189.101.64]) by jpoiret.xyz (Postfix) with ESMTPA id 2AAE5184F64; Fri, 20 May 2022 18:20:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpoiret.xyz; s=dkim; t=1653070847; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bdAJ3Y2LxvmEtimF6D19dLrwkaorzN5zaNIh9qiZTmw=; b=A6xLQJrqJeTt05+09NhiS6UMhS0GbZMgZ6hWA7h4yReGxZwxVDz4oSWUkKig/UQ6ymCB3x 0kd3pr3chdwHqBXAHjqMEWyhMi6EU+l47YdlmK7Yx1xHQ4CRsW6TAet8X0giVdhPhk8dKb M3OHWpOF5vuqMnkJjspNr2fI/HcRMc3beut4z1ST5bpIGgfYU67SGHSOo0IrvEVEjjgLSP Z+G2+yF+WARo8L3HqJgs0kHNdbgeVY9C/3MTM5FBPdSLtle1koEhHRRFROWBNFRSZwzndz ZfxAEZWN6efV8v1xDtOxw7zYakYPTD0zdYn2nkBQoqLZZqEZy987TOsSVSP5hg== From: Josselin Poiret To: Glenn Washburn Cc: grub-devel@gnu.org, Josselin Poiret Subject: [PATCH v3 0/2] Have LUKS2 cryptomounts be useable with grub-probe Date: Fri, 20 May 2022 20:20:37 +0200 Message-Id: <20220520182039.21654-1-dev@jpoiret.xyz> In-Reply-To: <20220512173852.5cb23d65@crass-HP-ZBook-15-G2> References: <20220512173852.5cb23d65@crass-HP-ZBook-15-G2> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Authentication-Results: jpoiret.xyz; auth=pass smtp.auth=jpoiret@jpoiret.xyz smtp.mailfrom=dev@jpoiret.xyz X-Spamd-Bar: ++++ Received-SPF: pass client-ip=206.189.101.64; envelope-from=dev@jpoiret.xyz; helo=jpoiret.xyz X-Spam_score_int: 4 X-Spam_score: 0.4 X-Spam_bar: / X-Spam_report: (0.4 / 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, FROM_SUSPICIOUS_NTLD=0.499, PDS_OTHER_BAD_TLD=1.997, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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: Fri, 20 May 2022 18:20:56 -0000 Hello Glenn, Thanks for your review! I've adressed all of your comments with these revised patches (only the second one has changed), with the caveats below: Glenn Washburn writes: > >> + grub_util_error (_("can't set dm task name to `%s'"), name); >> + if (!dm_task_run (dmt)) >> + grub_util_error (_("can't run dm task for `%s'"), name); >> + dm_get_next_target (dmt, NULL, &start, &length, >> + &target_type, ¶ms); > > It looks like this might return NULL on error? Or does it never error > here? dm_get_next_target only unpacks the result of a dm_task, it does no error handling at all. We only need the first (and only) target here, hence the NULL parameter. > [...] > >> + /* This is the only hash usable by PBKDF2, so set it as such */ >> + cryptodisk->hash = grub_crypto_lookup_md_by_name ("sha256"); > > So does this mean that when/if argon2 support is added, that this will > need to be detected as well? If so, is there a way to get the hash via > devmapper? It doesn't show up with the table command, so I'm guessing > not. On the otherhand, I don't think cryptodisk->hash is ever used in > the user-space utilities because the cryptodisk is never attempted to > be unlocked, so there's no password to hash. Perhaps this should be > NULL with a comment that its not used (if I'm right about that). Looking at the LUKS2 spec (see Key Derivation Object, section 3.2.5 of [1]), it doesn't seem that argon2 has a way to specify different hash functions, so I don't think we would need to detect that. We need to set cryptodisk->hash though so that the right abstractions are picked up and included by grub-install in the binary (this was my motivation for this whole thing in the first place)! > [...] > >> + else >> + sector_size_str = c; >> + sector_size = grub_strtoull (sector_size_str, NULL, 10); > > This should check for in grub_strtoull errors as is done in commit > ac8a37dda (net/http: Allow use of non-standard TCP/IP ports). I didn't spot anything out of the ordinary in that commit, but note that just after grub_strtoull, we check that sector_size is either 512, 1024, 2048 or 4096, and error if it isn't (unlikely). In any case, I've tested this in a VM with a LUKS2 device that has a 4096 sector_size, and `-v` does indeed report the right sector_size as well as the number of (encryption) sectors! Installation of GNU Guix went as expected on it, I even stacked LVM with BTRFS on top and everything worked properly. [1] https://gitlab.com/cryptsetup/LUKS2-docs/blob/master/luks2_doc_wip.pdf Best, Josselin Poiret (2): devmapper/getroot: Have devmapper recognize LUKS2 devmapper/getroot: Set up cheated LUKS2 cryptodisk mount from DM parameters grub-core/osdep/devmapper/getroot.c | 138 +++++++++++++++++++++++++++- 1 file changed, 133 insertions(+), 5 deletions(-) -- 2.36.0