From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1nsCky-00005V-5Y for mharc-grub-devel@gnu.org; Fri, 20 May 2022 20:14:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60600) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nsCkw-0008Q5-3H for grub-devel@gnu.org; Fri, 20 May 2022 20:14:06 -0400 Received: from mail-vs1-xe32.google.com ([2607:f8b0:4864:20::e32]:39477) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nsCkt-0005LY-P3 for grub-devel@gnu.org; Fri, 20 May 2022 20:14:05 -0400 Received: by mail-vs1-xe32.google.com with SMTP id c26so9811278vsl.6 for ; Fri, 20 May 2022 17:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficientek-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=ZeyaurLEkCTqRoqZDDSrBXKRcW2WPs/BqKc1bLsUDcA=; b=v9jupjFdS7Gb5yy4RuzL+5Yp1L/lU/Hkb1+hj2GtLGfzeuywBNDcx+QXauUJSEfUOT NyZ3/zXmGGkYMUTmAT4m85QYVCtxCvsvRuck836va4O1Hko9eSbPDQaVJXR9czOwlFND jzBp2TSyNoZX86Kjan+KhyKd4U1KCm8z8GClMLVYcBAJXoaUR61IgutQDuJJQF4K7Z8D GDQpsAx8FW5HRSt+imICs/SsE0Aoea3ogRVfW+Dd5BzQAb85pHLtZZsOxVJls5/apu+0 CnriLPFhPWRypJXXgH9E2mueRpPLXhuQyQ28E9y9R4XP39OB/YuM7Kd96caq7HfxYLbS PfPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=ZeyaurLEkCTqRoqZDDSrBXKRcW2WPs/BqKc1bLsUDcA=; b=R0GDbAbJ6KS/huD1ZM0D/JGPGfutby7LJFZ9rVps0soTMHMiwUBdWjX+ThODkzbZDG VDM/ITdGLe4KvufrKt+RkoNY2TtmVlMW5PRw1cVfBY4UQCXGFyOlyK74op0Wmnt07U5z O/sw8PvMJqBog/AzX+qTgdoae0bY2f0HXoyJkO7lq1VC5snKJU/7d+SuDE7lALJW1pd5 YTM5xcagfZgGiqkn7oenFU7CBRFuFb0ydl4wLt46nk7khLUOIHne+8w4OoM1PiGsu+sH z4Us3uluAoMp4KnkgzZkAFRXA86XJUnajP6txBAEtfPMyPurQStJZ5bIVYOOoU0BnKCj x/3g== X-Gm-Message-State: AOAM531DvK+Rq4QxEb95iWUqovzQMZjuC4jEcsBaBSgKZK2mD2NzRj4k XjfJVjYv6P01Qc/0zY0C4lSynMjGuMlg2w== X-Google-Smtp-Source: ABdhPJytw040DLcsi/eVtDTAv7zKvz0Aa27/6ojGaFjzl0ChBGOmsXChPE6DQpq/oTBibX+3ZUybhQ== X-Received: by 2002:a05:6102:4194:b0:337:997f:4acf with SMTP id cd20-20020a056102419400b00337997f4acfmr479955vsb.44.1653092041944; Fri, 20 May 2022 17:14:01 -0700 (PDT) Received: from crass-HP-ZBook-15-G2 ([37.218.244.249]) by smtp.gmail.com with ESMTPSA id u1-20020a1f2e01000000b00356b765b31asm662825vku.39.2022.05.20.17.13.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 May 2022 17:14:01 -0700 (PDT) Date: Fri, 20 May 2022 19:13:53 -0500 From: Glenn Washburn To: Josselin Poiret via Grub-devel , Fabian Vogt , Josselin Poiret Cc: Patrick Steinhardt , Michael Chang , Pierre-Louis Bonicoli Subject: Re: [PATCH 3/4] luks2: set up dummy sector size during scan Message-ID: <20220520191353.2d55b59a@crass-HP-ZBook-15-G2> In-Reply-To: <877da6rf6s.fsf@jpoiret.xyz> References: <43151052.QDiU1Cuimh@linux-e202.suse.de> <8735mkbj26.fsf@jpoiret.xyz> <2946843.ILLGAiG1oY@linux-e202.suse.de> <877da6rf6s.fsf@jpoiret.xyz> Reply-To: development@efficientek.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2607:f8b0:4864:20::e32; envelope-from=development@efficientek.com; helo=mail-vs1-xe32.google.com 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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: Sat, 21 May 2022 00:14:06 -0000 On Mon, 07 Feb 2022 14:15:07 +0100 Josselin Poiret via Grub-devel wrote: > Hi Fabian, > > Fabian Vogt writes: > > > Did you have a look at my approach? That effectively does the same, but using a > > single ioctl instead of anything complex with DM directly. I skipped this thread because I didn't really care about probing for LUKS2 (I don't use it). However, things change and now I'm evaluating the different patch series that implement this. I had missed Fabian's patch and I'm just now seeing it and this thread. Now that I've taken a look at Fabian's patch, I think its the better way to go for getting the sector size. The reason is that it uses grub_util_get_fd_size() to get the size and sector size of the cheat mount device. That function's implementation is platform dependant. So, for instance, if FreeBSD has a LUKS* implementation that is not libdevicemapper based, we'll correctly get the number of sectors and sector size. But yes, its very unlikely that FreeBSD will support LUKS. However, this same code should allow us to get the correct sector size for GELI devices also. I don't believe GRUB has GELI probe support, so ths would make things easier for whoever wants to develop it. The same goes for future cryptodisk backends. > I agree that it's sufficient for sector_size, but we still need the > cryptodisk algorithm so that grub-install will know which crypto modules > to include. libdm is actually a helper library around dm-specific I'm now thinking that GRUB should use Fabian's patch to get the sector size and number of sectors and Josselin's method of querying device mapper to get the other properies. We could have Josselin's patch first check if log_sector_size is set and if not then try to get it from DM. However, I think that's overkill and not really useful because grub_util_get_fd_size() should always give us the correct information, otherwise we've found a kernel bug. Also, by not having to parse out the sector size from the dm-crypt params string, we avoid much the complexity of that code, which has been the source of several bugs in reviewing a couple iterations of that patch. > ioctls, since they are apparently annoying to use, so in the end we're > still using the same interface :) Technically different interface, the code Fabian is using is not using device mapper related ioctls, they are generic block device ioctls (on Linux systems). > As for the 4 patches, since the actual sector_size is available to us, I > think using 512 in all cases or adding a specific 0 sector_size is > something we should avoid. I agree. Fabian, would you be able to send an updated patch with Patrick's suggestions in the near future? Glenn