Re: [PATCH v3 2/2] devmapper/getroot: Set up cheated LUKS2 cryptodisk mount from DM parameters
Hello Glenn, Glenn Washburn writes: > After reviewing this, I stumbled upon Fabian's patch. I wrote a > response on the thread of that patch with the suggestion that his patch > be used to get the total number of sectors and sector size and this > patch be used to get the crypto information. This would obviate the > problematic parsing part of this patch. What do you think about > removing all the parsing code after the setting of cryptodisk->hash? I just read that mail, and it does seem like the proper way (I don't need much convincing to remove most of that ugly parsing code!). I'll send a cleaned up patch later with all the logic errors adressed, and without the further sector size code. Best, -- Josselin Poiret ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 3/4] luks2: set up dummy sector size during scan
Hi, 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. Cheers, Fabian > Glenn ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[RFC] 64-bit boot protocol for Linux x86
Hi guys, If I understand the Linux boot correctly, GRUB 2 will drop Linux in a 32-bit protected mode, using the Linux 32-bit boot protocol. Since Linux has a 64-bit boot protocol, I'm thinking that we can make use of that. On x86_64 target, if we can use 64-bit boot protocol, we'll drop Linux in long mode directly, thus less code executed in the GRUB side, and less code in Linux side. Obviously it's cleaner to just use 32-bit protocol to boot both i386 and x86_64 kernel, but this will not add much complexity. Just new to this mailing list, am I missing anything? Wei Zhang ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[RFC] 64-bit boot protocol for Linux x86
Hi guys, If I understand the Linux boot correctly, GRUB 2 will drop Linux in a 32-bit protected mode, using the Linux 32-bit boot protocol. Since Linux has a 64-bit boot protocol, I'm thinking that we can make use of that. On x86_64 target, if we can make use of 64-bit boot protocol, we'll drop Linux in long mode directly, thus less code executed in the GRUB side, and less code in Linux side. Obviously it's cleaner to just use 32-bit protocol to boot both i386 and x86_64 kernel, but this will not add much complexity. Just new to this mailing list, am I missing anything? Wei Zhang___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] 64-bit boot protocol for Linux x86
Sorry about having sent the message twice, please ignore the previous one. Wei Zhang On Sun, May 22, 2022 at 11:56 AM Wei Zhang wrote: > > Hi guys, > If I understand the Linux boot correctly, GRUB 2 will drop Linux in a 32-bit > protected mode, > using the Linux 32-bit boot protocol. > Since Linux has a 64-bit boot protocol, I'm thinking that we can make use of > that. On x86_64 > target, if we can make use of 64-bit boot protocol, we'll drop Linux in long > mode directly, thus > less code executed in the GRUB side, and less code in Linux side. > Obviously it's cleaner to just use 32-bit protocol to boot both i386 and > x86_64 kernel, but this > will not add much complexity. > Just new to this mailing list, am I missing anything? > > Wei Zhang > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
