From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1no9yj-00051k-DH for mharc-grub-devel@gnu.org; Mon, 09 May 2022 16:27:37 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47010) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1no9yi-00051L-5J for grub-devel@gnu.org; Mon, 09 May 2022 16:27:36 -0400 Received: from jpoiret.xyz ([206.189.101.64]:58458) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1no9yf-0000et-Qa for grub-devel@gnu.org; Mon, 09 May 2022 16:27:35 -0400 Received: from authenticated-user (jpoiret.xyz [206.189.101.64]) by jpoiret.xyz (Postfix) with ESMTPA id 73128184BF2; Mon, 9 May 2022 20:27:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpoiret.xyz; s=dkim; t=1652128051; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/jr5kmAXT52yq5nlrJ7OexJT/n9XmeS23EOnx/S4MuM=; b=apnz85X8DuLpM5VJ6rdxUOmk9xmsf3FWK92RRtDD11JZXvOt4gntsmjlcVmHPPm+x3mdj7 PuNYY1VuHkm8UledsV++cSqsiF7kYrc7+63QpaoVtXKsXpMjc9Gqq2vI9ooQ2gGToRWZNR e5fND0c1nhTG22o+oB0rNq65UoHy5uVXQ9/0jT2WsbKBc+sLQgd+uuNO9sgLFfQqMvSuxJ hDzUhFY7Avp4qYJ4hGflIq/lbo/q4dL1Dcn4F8lt8lWqLr4stQ430Dd9aQHhHP5yY5djUN mfxvRSozLzk9JBTrTUrbUi39krjKUq1JSz+JhlzDoEQ5wEnd4VVWGrToHRAn9g== From: Josselin Poiret To: Glenn Washburn , Pierre-Louis Bonicoli Cc: The development of GNU GRUB Subject: Re: [PATCH v2 3/3] grub-core/kern/disk.c: handle LUKS2 devices In-Reply-To: <20220504164708.5322406a@crass-HP-ZBook-15-G2> References: <20220329103158.4096409-1-pierre-louis.bonicoli@libregerbil.fr> <20220329103158.4096409-4-pierre-louis.bonicoli@libregerbil.fr> <20220504164708.5322406a@crass-HP-ZBook-15-G2> Date: Mon, 09 May 2022 22:27:30 +0200 Message-ID: <87ee12tpsd.fsf@jpoiret.xyz> MIME-Version: 1.0 Content-Type: text/plain 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: Mon, 09 May 2022 20:27:36 -0000 Hello everyone, Glenn Washburn writes: > I don't really like this, but it gets the job done and is a work-around > for a peculiarity of the LUKS2 backend. The cheat mount code for > cryptodisk does only calls scan() and not recover_key(). For LUKS1 scan > will return a grub_cryptodisk_t with log_sector_size set, but LUKS2 > will not. This is because for LUKS1 the log_sector_size is constant > (LUKS1 also sets most of the other properties of the cryptodisk device, > like crypto algorithm, because they are in the binary header). However, > for LUKS2 the sector size (along with other properties) is in the json > header, which isn't getting parsed in scan(). > > For single segment LUKS2 containers, scan() could get the sector size > from the json segment object. The LUKS2 spec says that normal LUKS2 > devices are single segment[1], so this should work in the the cases the > care about (currently). scan() would not be able to fill in the other > properties, like crypto algorithm, because that depends on the keyslot > used, which needs key recovery to be determined. To avoid parsing the > json data twice, once in scan() and once in recover_key(), which should > be avoided, the parsed json object could be put in the grub_cryptodisk_t > in scan(), and used and freed in recover_key(). We'd probably also want > to add a way for grub_cryptodisk_t objects to get cleaned up by the > backend using them, so that the json object could be freed even if > recover_key() is never called. > > I think the above is the real fix, a moderate amount more work, and not > something I'd expect Pierre-Louis to take up. So if we're not going to > do this to get this functionality to work, we'll need a hack to get it > working. However, I'd prefer a different one. > > I've not tested this, but it seems to me that we can set the > log_sector_size field to GRUB_DISK_SECTOR_BITS _if_ it equals zero in > grub_cryptodisk_cheat_insert(). This limits the hack to only GRUB > host/user-space code. Regarding these last lines, it's also possible to directly ask dm for the actual sector size when cheatmounting, as well as the crypto algorithm, bypassing the whole issue of parsing the json and finding the right slot. This is roughly what's done in patch 2 of [1], maybe this workaround would be more to your liking? I've distributed this patch to several people that were having issues on GNU Guix and they've been happily using LUKS2 with GRUB with it. [1] https://lists.gnu.org/archive/html/grub-devel/2021-12/msg00079.html (20211211122945.6326-1-dev@jpoiret.xyz) Best, -- Josselin Poiret