Hi,
Am Mittwoch, 22. Dezember 2021, 19:17:37 CET schrieb Josselin Poiret via
Grub-devel:
> Hello everyone,
>
> Fabian Vogt <fv...@suse.de> writes:
> > It looks like we have a third patch (series) for this feature meanwhile:
> > [PATCH 0/2] Have LUKS2 cryptomounts be useable with grub-probe
> >
> > I CC'd the author, let's try to coordinate.
And there's a forth one now (author CC'd)!
("[PATCH 3/3] grub-core/kern/disk.c: handle LUKS2 devices")
So we have:
"[PATCH 3/4] luks2: set up dummy sector size during scan", which hardcodes 512,
"[PATCH 1/2] disk/cryptodisk: When cheatmounting, use the sector info of the
cheat device", which queries the sector size of the underlying host device,
"[PATCH v2 2/2] devmapper/getroot: Set up cheated LUKS2 cryptodisk mount from
DM parameters", which parses the DM table to get the sector_size, and now
"[PATCH 3/3] grub-core/kern/disk.c: handle LUKS2 devices", which changes the
grub core code to accept a sector size of 0 for LUKS2 devices.
Should be enough options to pick a good one ;-)
> > Thanks,
> > Fabian
>
> Let me just say that I had not found this patch series while searching
> beforehand. Let me just recap what my patches do differently (in
> relation to patches 3 and 4 of this series):
>
> Because cheat-mounting cryptodisks only happens (from my understanding)
> when pulling devmapper devices, we can simply ask the kernel for the dm
> and dm-crypt parameters that it's opened with, and populate our
> cheat-mounted device from that. This completely circumvents the multiple
> segments issue, as this will always yield the parameters corresponding
> to the user-specified mountpoint of `grub-probe` or `grub-install`.
Yup.
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 also opted not to add a GRUB_DEV_ABSTRACTION_LUKS2 abstraction, so as
> to reuse all existing code that supports LUKS1, although that can be
> confusing. We could simply rename GRUB_DEV_ABSTRACTION_LUKS1 to
> GRUB_DEV_ABSTRACTION_CRYTODISK, as LUKS1 and LUKS2 only differ in how
> they're unlocked, not in underlying algorithms.
>
> What do you think?
Sounds good to me, though I'd count that as a separate refactoring step for
the future.
Cheers,
Fabian
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
