[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/4] luks2: set up dummy sector size during scan

From: Fabian Vogt
Subject: Re: [PATCH 3/4] luks2: set up dummy sector size during scan
Date: Sat, 21 May 2022 12:53:04 +0200


Am Samstag, 21. Mai 2022, 02:13:53 CEST schrieb Glenn Washburn:
> 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?

Sure! I'll be back from vacation after end of May, I hope that still counts.


> Glenn

reply via email to

[Prev in Thread] Current Thread [Next in Thread]