From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oJMpj-00081B-6E for mharc-grub-devel@gnu.org; Wed, 03 Aug 2022 18:27:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39096) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJMpc-0007l5-Bk for grub-devel@gnu.org; Wed, 03 Aug 2022 18:27:12 -0400 Received: from msg-1.mailo.com ([213.182.54.11]:39074) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJMpW-0002D3-5S for grub-devel@gnu.org; Wed, 03 Aug 2022 18:27:11 -0400 Received: by www.mailo.com with http webmail; Thu, 4 Aug 2022 00:26:58 +0200 (CEST) X-EA-Auth: 4cf/UKujXMJYgPHQxK64jaIa4RTSaRhQcvoBJk4hlkCt2vp6a2WWoXT3MOeRgOQNdpxadbiQDsa1xTl8OQQlS5NRKSpjxEah From: brutser@perso.be To: grub-devel@gnu.org Cc: dkiper@net-space.pl, ps@pks.im Date: Thu, 4 Aug 2022 00:26:58 +0200 (CEST) Subject: Re: [PATCH v3 0/3] Cryptomount detached headers X-Priority: 3 MIME-Version: 1.0 X-Mailer: COMS/EA22.05/r20220615 Message-ID: In-Reply-To: <20220803145414.42d7867f@crass-HP-ZBook-15-G2> Content-Type: multipart/alternative; boundary="----=_NextPart_001_62eaf632_3e34_7422a3c1" Received-SPF: pass client-ip=213.182.54.11; envelope-from=brutser@perso.be; helo=msg-1.mailo.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, HTML_MESSAGE=0.001, 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: Wed, 03 Aug 2022 22:27:12 -0000 ------=_NextPart_001_62eaf632_3e34_7422a3c1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable See comments below. Van: Glenn Washburn Aan: brutser--- via Grub-devel Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers Datum: 03/08/2022 21:54:14 Europe/Paris Cc: brutser@perso.be; =C2=A0=C2=A0=C2=A0dkiper@net-space.pl; =C2=A0=C2=A0=C2=A0ps@pks.im On Tue, 2 Aug 2022 22:49:27 +0200 (CEST) brutser--- via Grub-devel wrote: >=20 > Van: Glenn Washburn > Aan: brutser--- via Grub-devel > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers > Datum: 02/08/2022 20:58:17 Europe/Paris > Cc: brutser@perso.be; > =C2=A0=C2=A0=C2=A0dkiper@net-space.pl; > =C2=A0=C2=A0=C2=A0ps@pks.im >=20 > Hi Bruster, >=20 > Are you able to add your responses inline like I have been doing in my > replies? And not top-post, which is posting at the top. >=20 > I will reply here, though my mail client is not really doing a great job= to get this inline response done, sorry for that. Ok, I figured that. However, you've not responded to much of my comments that I wrote inline. Perhaps you only read the first part of my response and do not realize that I wrote more response further down. Please look at the full email until you see my name, which indicates that I am finished responding. Please respond to all of my questions, otherwise it makes it difficult to help you and if you don't take the time to respond to me fully I am less inclined to help. I would like to get this issue sorted out, but I need you to help me debug it right now. Also, I have never built GRUB with coreboot, so I don't have a way to precisely reproduce your setup anyway. And it currently does work for me. Glenn >>> Comments: I think I read all your comments and tried to reply as best as possible. I tried the following test to eliminate the coreboot issue >> Qemu installation: 1. Minimal Debian 11.4 installation on /dev/sda1 2. git clone latest grub, make & make install, grub-install 3. Reboot Debian iso > =C2=A0=C2=A0=C2=A0 Expert install Debian 11.4 =C2=A0=C2=A0=C2=A0 Exit to Shell > =C2=A0=C2=A0=C2=A0 cryptsetup luksFormat --type luks2 -q -h sha512 -s 512 = --pbkdf pbkdf2 --header /root/header.bin --luks2-metadata-size=3D16k --luks= 2-keyslots-size=3D512k /dev/sda2 =C2=A0=C2=A0=C2=A0 cryptsetup luksOpen --header /root/header.bin /dev/sda2= sda2crypt =C2=A0=C2=A0=C2=A0 pvcreate /dev/mapper/sda2crypt =C2=A0=C2=A0=C2=A0 vgcreate testvg /dev/mapper/sda2crypt =C2=A0=C2=A0=C2=A0 lvcreate -l 100%FREE -n root testvg 4. Complete minimal debian 11.4 installation on encrypted lvm 5. Save header to /dev/sda1 6. Copy header file to target initramfs, populate crypttab, some scripts t= o finish the encryption 7. Finish installation and reboot. 8. Exit to Grub cmd > =C2=A0=C2=A0=C2=A0 insmod luks2 =C2=A0=C2=A0=C2=A0 insmod lvm =C2=A0=C2=A0=C2=A0 insmod cryptodisk =C2=A0=C2=A0=C2=A0 cryptomount -H (hd0,msdos1)/header.bin (hd0,msdos2) result: error: no cryptodisk module can handle this device. >=20 > Let me be clear on my testing environment, I was purely testing latest g= rub as payload for coreboot, so even on qemu, I am using coreboot for BIOS = with my compiled grub as one of the payloads. > I am testing on a basic Thinkpad laptop with x86_64 architecture. >=20 > "I'm not sure I understand why you're saying this.", I was basically jus= t expressing that I was testing the functionality purely for my own setup, = so if you wanted me to test more general (for example without coreboot), th= en you could say me. > Not that it shouldn't work with coreboot obviously, but if other testing= could give more accurate results and debug logs for example, I am willing = to do that, that was all. >=20 > On Tue, 2 Aug 2022 02:26:58 +0200 (CEST) > brutser--- via Grub-devel wrote: >=20 > >=20 > >=20 > > Glenn, > >=20 > >=20 > >=20 > > But my testing is very limited, i only create grub payload for coreboo= t and then i create the encrypted sda2 from the debian expert installer etc= . >=20 > I'm not sure I understand why you're saying this. Did I ask you to do > something that you think you can't do because your "testing is very > limited"? You've proven capable of modifying the source code to add > debug log messages and successfully reproducing the issue in QEMU. That > makes your testing ability not very limited in my opinion. What am I > missing that you're wanting to convey here? >=20 > Since you've reproduced the issue in QEMU and I'm assuming that you're > not running coreboot in QEMU, then I conclude that coreboot is not a > relevant factor here. What exactly was the QEMU commandline you used in > getting the output you previously created? Did you ever try to get the > serial output with the QEMU options I suggested previously? >=20 > >=20 > > If you got suggestions with this setup, how i can do another way of te= sting, let me know and I will do it. >=20 > Why do you need another way of testing? As I mentioned above you can > modify the source code of GRUB and run that modified GRUB in QEMU. I > don't think we need another way. Were you having problems adding the > debug message to cryptodisk_read_hook I suggested in my last response? > I'm starting to think there is an issue in the hook mechanism, but I'd > like your help in confirming that. >=20 > >=20 > > Van: brutser--- via Grub-devel > > Aan: grub-devel@gnu.org > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers > > Datum: 02/08/2022 01:47:57 Europe/Paris > > Cc: brutser@perso.be; > > =C2=A0=C2=A0=C2=A0dkiper@net-space.pl; > > =C2=A0=C2=A0=C2=A0ps@pks.im > >=20 > >=20 > >=20 > > Debian 11.4 for all the testing. >=20 > Thanks for this info, but that wasn't what I was asking for. I asked > for the architecture and endianness. For example, are you running on > x86_64 or i386 (64-bit vs 32-bit) x86 architecture? These are always > little endian. But you could be running on a MIPS architecture that can > be either big or little endian. I want this confirmed so I can get the > full picture. I'm doubting now that this is important, but you never > know. >=20 > From your response below, I believe that the host and the target are > the same machine, but are you building GRUB on that machine as well? > Are you running QEMU for testing on that machine as well? >=20 > I haven't tried to reproduce this issue locally yet due to time > constraints and it may be a while before I can get to it. But we're > getting close to the point where it may require me doing that. >=20 > Glenn >=20 > >=20 > > as i said, i execute shell during installation, then simply enter the = commands I wrote earlier: > >=20 > >=20 > >=20 > > cryptsetup luksFormat --type luks2 -q -h sha512 -s 512 --pbkdf pbkdf2 = --header /root/header.bin --luks2-metadata-size=3D16k --luks2-keyslots-size= =3D512k /dev/sda2 > >=20 > > cryptsetup luksOpen --header /root/header.bin /dev/sda2 sda2crypt > >=20 > > pvcreate /dev/mapper/sda2crypt > >=20 > > vgcreate testvg /dev/mapper/sda2crypt > >=20 > > lvcreate -L 2G -n root testvg > >=20 > >=20 > >=20 > > - continue install debian 11.4 > >=20 > > - chroot into system > >=20 > > - copy header > >=20 > > - populate crypttab etc. > >=20 > >=20 > >=20 > > this whole process works 100% fine with grub 2.04 and luks1 as i said = before... > >=20 > >=20 > >=20 > >=20 > >=20 > > Van: Glenn Washburn > > Aan: brutser--- via Grub-devel > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers > > Datum: 02/08/2022 01:24:47 Europe/Paris > > Cc: brutser@perso.be; > > =C2=A0=C2=A0=C2=A0dkiper@net-space.pl; > > =C2=A0=C2=A0=C2=A0ps@pks.im > >=20 > > On Tue, 2 Aug 2022 00:21:09 +0200 (CEST) > > brutser--- via Grub-devel wrote: > >=20 > > > Glenn, > > >=20 > > >=20 > > >=20 > > > Still resorted to screenshots for the debug (with the added dprintf)= : > > >=20 > > >=20 > > >=20 > > > https://imgur.com/a/YkVMdBe > >=20 > > Ok, that confirms that the luks2 module is loaded and that the scan is > > happening. Based on the output I think luks2_read_header must be > > failing. That means that either disk reads are failing, which doesn't > > seem like the case, the disk read hook is failing or the LUKS2 magic > > bytes are not what they should be. > >=20 > > Have you verified that after creating the volume and header file that > > cryptsetup/dm can open the volume successfully? > >=20 > > What architecture and endianness is the machine you're running > > cryptsetup on and what is it for the one GRUB is running on? > >=20 > > To test the read hook, add 'grub_dprintf("luks2", "read hook > > successed");' just before the last return statement in the function > > cryptodisk_read_hook in grub-core/disk/cryptodisk.c. > >=20 > > Glenn > >=20 > > >=20 > > >=20 > > >=20 > > > Van: Glenn Washburn > > > Aan: brutser--- via Grub-devel > > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers > > > Datum: 01/08/2022 22:50:27 Europe/Paris > > > Cc: brutser@perso.be; > > > =C2=A0=C2=A0=C2=A0dkiper@net-space.pl; > > > =C2=A0=C2=A0=C2=A0ps@pks.im > > >=20 > > > On Sat, 30 Jul 2022 11:54:32 +0200 (CEST) > > > brutser--- via Grub-devel wrote: > > >=20 > > > > Glenn, > > > >=20 > > > >=20 > > > >=20 > > > > As I had no idea how to get the debug logs from qemu, I made scree= nshots, find them attached. As this is probably something I am doing wrong,= I hope it shows from the logs. > > > >=20 > > > > https://imgur.com/a/rAlfZ77 > > >=20 > > > Getting the output to go to serial depends on the target. For i386 > > > using seabios, use "-fw_cfg name=3Detc/sercon-port,string=3D0 -seria= l > > > stdio". > > >=20 > > > Unfortunately, I'm now seeing that there are no debug log messages > > > in the luks2 module that would be shown in this case. How about putt= ing > > > the line 'grub_dprintf("entering luks_scan");' at the start of the > > > function luks2_scan in grub-core/disk/luks2.c and then recompiling a= nd > > > getting the output? > > >=20 > > > Glenn > > >=20 > > >=20 > > > >=20 > > > > Van: Glenn Washburn > > > > Aan: brutser@perso.be > > > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers > > > > Datum: 29/07/2022 21:27:48 Europe/Paris > > > > Cc: grub-devel@gnu.org; > > > > =C2=A0=C2=A0=C2=A0dkiper@net-space.pl; > > > > =C2=A0=C2=A0=C2=A0ps@pks.im > > > >=20 > > > > On Fri, 29 Jul 2022 20:56:18 +0200 (CEST) > > > > brutser@perso.be wrote: > > > >=20 > > > > >=20 > > > > > testing detached header failed: > > > > >=20 > > > > >=20 > > > > >=20 > > > > > 1. built grub payload with following modules: ahci usb_keyboard = part_msdos part_gpt at_keyboard cbfs cryptodisk luks2 lvm gcry_rijndael gcr= y_sha1 gcry_sha256 gcry_sha512 > > > > >=20 > > > > > 2. encrypt a partition: cryptsetup luksFormat --type luks2 -q -h= sha512 -s 512 --pbkdf pbkdf2 --header /path/to/header --luks2-metadata-siz= e=3D16k --luks2-keyslots-size=3D512k /dev/sda1 > > > > >=20 > > > > > (where --luks2-metadata-size=3D16k --luks2-keyslots-size=3D512k = is optional, this is just to minimize header size, but I also tested withou= t). > > > > >=20 > > > > > 3. from the grub cmd, i try to decrypt this partition using: cry= ptomount -H /path/to/header (ahci0,msdos1) > > > > >=20 > > > > >=20 > > > > >=20 > > > > > 4. I also tried luks1 encryption with detached header. > > > > >=20 > > > > >=20 > > > > >=20 > > > > > whatever I try, I always get the same error: > > > > >=20 > > > > > "no cryptodisk module can handle this device" > > > > >=20 > > > > >=20 > > > > >=20 > > > > > Is this feature not 100% implemented yet, I saw people already v= erifying the patches and would expect this to be working, so if yes, this s= eems like a bug. > > > >=20 > > > > This feature should be working in all cases, and if not there may = be a > > > > bug. I responded to your off-list email before seeing this one. I'= ll > > > > repeat what I said there and let's continue this discussion on the= list. > > > >=20 > > > > I see nothing obviously wrong with what you're doing, given the > > > > information above. To further debug this, would you be able to sen= d a > > > > log of the serial output when the GRUB envvar debug is set to "all= " > > > > while running the cryptomount command? If so, please send compress= ed in > > > > a reply to this email on the list. > > > >=20 > > > > If you can't because of hardware issues, would you be able to repl= icate > > > > this in QEMU and grab the serial output from there? If you can boo= t the > > > > system via other means, you should be able to use the raw disks (t= he > > > > one with the LUKS volume and the other with the filesystem contain= ing > > > > the header file). > > > >=20 > > > > Glenn > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Grub-devel mailing list > > > > Grub-devel@gnu.org > > > > https://lists.gnu.org/mailman/listinfo/grub-devel > > > >=20 > > >=20 > > > _______________________________________________ > > > Grub-devel mailing list > > > Grub-devel@gnu.org > > > https://lists.gnu.org/mailman/listinfo/grub-devel > > >=20 > >=20 > > _______________________________________________ > > 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 > >=20 >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >=20 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ------=_NextPart_001_62eaf632_3e34_7422a3c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable See comments below.


Van: Glenn Washburn= <development@efficientek.com>
Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
Datum: 03/08/2022 21:54:14 Europe/Paris
Cc: brutser@perso.be;
=C2=A0=C2=A0=C2=A0dkiper@net-space.pl;
=C2=A0=C2=A0=C2=A0ps@pks.im

On Tue, 2 Aug 2022 22:49:27 +0200 (CEST)
brutser--- via Grub-devel <grub-devel@gnu.org> wrote:

>
> Van: Glenn Washburn <development@efficientek.com>
> Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 02/08/2022 20:58:17 Europe/Paris
> Cc: brutser@perso.be;
> =C2=A0=C2=A0=C2=A0dkiper@net-space.pl;
> =C2=A0=C2=A0=C2=A0ps@pks.im
>
> Hi Bruster,
>
> Are you able to add your responses inline like I have been doing in m= y
> replies? And not top-post, which is posting at the top.
>
> I will reply here, though my mail client is not really doing a great = job to get this inline response done, sorry for that.

Ok, I figured that. However, you've not responded to much of my
comments that I wrote inline. Perhaps you only read the first part of
my response and do not realize that I wrote more response further down. Please look at the full email until you see my name, which indicates
that I am finished responding. Please respond to all of my questions,
otherwise it makes it difficult to help you and if you don't take the
time to respond to me fully I am less inclined to help. I would like to get this issue sorted out, but I need you to help me debug it right now.
Also, I have never built GRUB with coreboot, so I don't have a way to
precisely reproduce your setup anyway. And it currently does work for
me.

Glenn

>>> Comments:
I think I read all your comments an= d tried to reply as best as possible.

I tried the following test to = eliminate the coreboot issue >>

Qemu installation:

1. M= inimal Debian 11.4 installation on /dev/sda1
2. git clone latest grub, m= ake & make install, grub-install
3. Reboot Debian iso >
=C2=A0= =C2=A0=C2=A0 Expert install Debian 11.4
=C2=A0=C2=A0=C2=A0 Exit to Shell= >
=C2=A0=C2=A0=C2=A0 cryptsetup luksFormat --type luks2 -q -h sha512= -s 512 --pbkdf pbkdf2 --header /root/header.bin --luks2-metadata-size=3D16= k --luks2-keyslots-size=3D512k /dev/sda2
=C2=A0=C2=A0=C2=A0 cryptsetup l= uksOpen --header /root/header.bin /dev/sda2 sda2crypt
=C2=A0=C2=A0=C2=A0= pvcreate /dev/mapper/sda2crypt
=C2=A0=C2=A0=C2=A0 vgcreate testvg /dev/= mapper/sda2crypt
=C2=A0=C2=A0=C2=A0 lvcreate -l 100%FREE -n root testvg<= br>4. Complete minimal debian 11.4 installation on encrypted lvm
5. Save= header to /dev/sda1
6. Copy header file to target initramfs, populate c= rypttab, some scripts to finish the encryption

7. Finish installatio= n and reboot.
8. Exit to Grub cmd >
=C2=A0=C2=A0=C2=A0 insmod luks= 2
=C2=A0=C2=A0=C2=A0 insmod lvm
=C2=A0=C2=A0=C2=A0 insmod cryptodisk<= br>=C2=A0=C2=A0=C2=A0 cryptomount -H (hd0,msdos1)/header.bin (hd0,msdos2)
result: error: no cryptodisk module can handle this device.

>
> Let me be clear on my testing environment, I was purely testing lates= t grub as payload for coreboot, so even on qemu, I am using coreboot for BI= OS with my compiled grub as one of the payloads.
> I am testing on a basic Thinkpad laptop with x86_64 architecture.
= >
> "I'm not sure I understand why you're saying this.", I was = basically just expressing that I was testing the functionality purely for m= y own setup, so if you wanted me to test more general (for example without = coreboot), then you could say me.
> Not that it shouldn't work with coreboot obviously, but if other test= ing could give more accurate results and debug logs for example, I am willi= ng to do that, that was all.
>
> On Tue, 2 Aug 2022 02:26:58 +0200 (CEST)
> brutser--- via Grub-devel <grub-devel@gnu.org> wrote:
>
> >
> >
> > Glenn,
> >
> >
> >
> > But my testing is very limited, i only create grub payload for c= oreboot and then i create the encrypted sda2 from the debian expert install= er etc.
>
> I'm not sure I understand why you're saying this. Did I ask you to do=
> something that you think you can't do because your "testing is v= ery
> limited"? You've proven capable of modifying the source code to = add
> debug log messages and successfully reproducing the issue in QEMU. Th= at
> makes your testing ability not very limited in my opinion. What am I<= br> > missing that you're wanting to convey here?
>
> Since you've reproduced the issue in QEMU and I'm assuming that you'r= e
> not running coreboot in QEMU, then I conclude that coreboot is not a<= br> > relevant factor here. What exactly was the QEMU commandline you used = in
> getting the output you previously created? Did you ever try to get th= e
> serial output with the QEMU options I suggested previously?
>
> >
> > If you got suggestions with this setup, how i can do another way= of testing, let me know and I will do it.
>
> Why do you need another way of testing? As I mentioned above you can<= br> > modify the source code of GRUB and run that modified GRUB in QEMU. I<= br> > don't think we need another way. Were you having problems adding the<= br> > debug message to cryptodisk_read_hook I suggested in my last response= ?
> I'm starting to think there is an issue in the hook mechanism, but I'= d
> like your help in confirming that.
>
> >
> > Van: brutser--- via Grub-devel <grub-devel@gnu.org>
> > Aan: grub-devel@gnu.org
> > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > Datum: 02/08/2022 01:47:57 Europe/Paris
> > Cc: brutser@perso.be;
> > =C2=A0=C2=A0=C2=A0dkiper@net-space.pl;
> > =C2=A0=C2=A0=C2=A0ps@pks.im
> >
> >
> >
> > Debian 11.4 for all the testing.
>
> Thanks for this info, but that wasn't what I was asking for. I asked<= br> > for the architecture and endianness. For example, are you running on<= br> > x86_64 or i386 (64-bit vs 32-bit) x86 architecture? These are always<= br> > little endian. But you could be running on a MIPS architecture that c= an
> be either big or little endian. I want this confirmed so I can get th= e
> full picture. I'm doubting now that this is important, but you never<= br> > know.
>
> From your response below, I believe that the host and the target are<= br> > the same machine, but are you building GRUB on that machine as well?<= br> > Are you running QEMU for testing on that machine as well?
>
> I haven't tried to reproduce this issue locally yet due to time
> constraints and it may be a while before I can get to it. But we're > getting close to the point where it may require me doing that.
>
> Glenn
>
> >
> > as i said, i execute shell during installation, then simply ente= r the commands I wrote earlier:
> >
> >
> >
> > cryptsetup luksFormat --type luks2 -q -h sha512 -s 512 --pbkdf p= bkdf2 --header /root/header.bin --luks2-metadata-size=3D16k --luks2-keyslot= s-size=3D512k /dev/sda2
> >
> > cryptsetup luksOpen --header /root/header.bin /dev/sda2 sda2cryp= t
> >
> > pvcreate /dev/mapper/sda2crypt
> >
> > vgcreate testvg /dev/mapper/sda2crypt
> >
> > lvcreate -L 2G -n root testvg
> >
> >
> >
> > - continue install debian 11.4
> >
> > - chroot into system
> >
> > - copy header
> >
> > - populate crypttab etc.
> >
> >
> >
> > this whole process works 100% fine with grub 2.04 and luks1 as i= said before...
> >
> >
> >
> >
> >
> > Van: Glenn Washburn <development@efficientek.com>
> > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > Datum: 02/08/2022 01:24:47 Europe/Paris
> > Cc: brutser@perso.be;
> > =C2=A0=C2=A0=C2=A0dkiper@net-space.pl;
> > =C2=A0=C2=A0=C2=A0ps@pks.im
> >
> > On Tue, 2 Aug 2022 00:21:09 +0200 (CEST)
> > brutser--- via Grub-devel <grub-devel@gnu.org> wrote:
> >
> > > Glenn,
> > >
> > >
> > >
> > > Still resorted to screenshots for the debug (with the added= dprintf):
> > >
> > >
> > >
> > > https://imgur.com/a/YkVMdBe
> >
> > Ok, that confirms that the luks2 module is loaded and that the s= can is
> > happening. Based on the output I think luks2_read_header must be=
> > failing. That means that either disk reads are failing, which do= esn't
> > seem like the case, the disk read hook is failing or the LUKS2 m= agic
> > bytes are not what they should be.
> >
> > Have you verified that after creating the volume and header file= that
> > cryptsetup/dm can open the volume successfully?
> >
> > What architecture and endianness is the machine you're running > > cryptsetup on and what is it for the one GRUB is running on?
= > >
> > To test the read hook, add 'grub_dprintf("luks2", &quo= t;read hook
> > successed");' just before the last return statement in the = function
> > cryptodisk_read_hook in grub-core/disk/cryptodisk.c.
> >
> > Glenn
> >
> > >
> > >
> > >
> > > Van: Glenn Washburn <development@efficientek.com>
= > > > Aan: brutser--- via Grub-devel <grub-devel@gnu.org> > > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers<= br> > > > Datum: 01/08/2022 22:50:27 Europe/Paris
> > > Cc: brutser@perso.be;
> > > =C2=A0=C2=A0=C2=A0dkiper@net-space.pl;
> > > =C2=A0=C2=A0=C2=A0ps@pks.im
> > >
> > > On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
> > > brutser--- via Grub-devel <grub-devel@gnu.org> wrote:=
> > >
> > > > Glenn,
> > > >
> > > >
> > > >
> > > > As I had no idea how to get the debug logs from qemu, = I made screenshots, find them attached. As this is probably something I am = doing wrong, I hope it shows from the logs.
> > > >
> > > > https://imgur.com/a/rAlfZ77
> > >
> > > Getting the output to go to serial depends on the target. F= or i386
> > > using seabios, use "-fw_cfg name=3Detc/sercon-port,str= ing=3D0 -serial
> > > stdio".
> > >
> > > Unfortunately, I'm now seeing that there are no debug log m= essages
> > > in the luks2 module that would be shown in this case. How a= bout putting
> > > the line 'grub_dprintf("entering luks_scan");' at= the start of the
> > > function luks2_scan in grub-core/disk/luks2.c and then reco= mpiling and
> > > getting the output?
> > >
> > > Glenn
> > >
> > >
> > > >
> > > > Van: Glenn Washburn <development@efficientek.com>= ;
> > > > Aan: brutser@perso.be
> > > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached hea= ders
> > > > Datum: 29/07/2022 21:27:48 Europe/Paris
> > > > Cc: grub-devel@gnu.org;
> > > > =C2=A0=C2=A0=C2=A0dkiper@net-space.pl;
> > > > =C2=A0=C2=A0=C2=A0ps@pks.im
> > > >
> > > > On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> > > > brutser@perso.be wrote:
> > > >
> > > > >
> > > > > testing detached header failed:
> > > > >
> > > > >
> > > > >
> > > > > 1. built grub payload with following modules: ahc= i usb_keyboard part_msdos part_gpt at_keyboard cbfs cryptodisk luks2 lvm gc= ry_rijndael gcry_sha1 gcry_sha256 gcry_sha512
> > > > >
> > > > > 2. encrypt a partition: cryptsetup luksFormat --t= ype luks2 -q -h sha512 -s 512 --pbkdf pbkdf2 --header /path/to/header --luk= s2-metadata-size=3D16k --luks2-keyslots-size=3D512k /dev/sda1
> > > > >
> > > > > (where --luks2-metadata-size=3D16k --luks2-keyslo= ts-size=3D512k is optional, this is just to minimize header size, but I als= o tested without).
> > > > >
> > > > > 3. from the grub cmd, i try to decrypt this parti= tion using: cryptomount -H /path/to/header (ahci0,msdos1)
> > > > >
> > > > >
> > > > >
> > > > > 4. I also tried luks1 encryption with detached he= ader.
> > > > >
> > > > >
> > > > >
> > > > > whatever I try, I always get the same error:
> > > > >
> > > > > "no cryptodisk module can handle this device= "
> > > > >
> > > > >
> > > > >
> > > > > Is this feature not 100% implemented yet, I saw p= eople already verifying the patches and would expect this to be working, so= if yes, this seems like a bug.
> > > >
> > > > This feature should be working in all cases, and if no= t there may be a
> > > > bug. I responded to your off-list email before seeing = this one. I'll
> > > > repeat what I said there and let's continue this discu= ssion on the list.
> > > >
> > > > I see nothing obviously wrong with what you're doing, = given the
> > > > information above. To further debug this, would you be= able to send a
> > > > log of the serial output when the GRUB envvar debug is= set to "all"
> > > > while running the cryptomount command? If so, please s= end compressed in
> > > > a reply to this email on the list.
> > > >
> > > > If you can't because of hardware issues, would you be = able to replicate
> > > > this in QEMU and grab the serial output from there? If= you can boot the
> > > > system via other means, you should be able to use the = raw disks (the
> > > > one with the LUKS volume and the other with the filesy= stem containing
> > > > the header file).
> > > >
> > > > Glenn
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> > >
> >
> > _______________________________________________
> > 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=
> >
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel<= br> >

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
------=_NextPart_001_62eaf632_3e34_7422a3c1--