From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oJtsJ-0005ZA-7O for mharc-grub-devel@gnu.org; Fri, 05 Aug 2022 05:44:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50962) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJtsC-0005HR-Oo for grub-devel@gnu.org; Fri, 05 Aug 2022 05:44:04 -0400 Received: from ip-15.mailobj.net ([213.182.54.15]:39744 helo=msg-4.mailo.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJts7-0002Co-TV for grub-devel@gnu.org; Fri, 05 Aug 2022 05:44:04 -0400 Received: by www.mailo.com with http webmail; Fri, 5 Aug 2022 11:43:51 +0200 (CEST) X-EA-Auth: vgVNmeYocKQPLzpthl69NXLy5ZSQQephJamaWptonPYSVmoKyk8P1/KSlPBrxty8SensEgYIQcDxFFKRs25T4+mOorh7QsWW From: brutser@perso.be To: grub-devel@gnu.org Cc: dkiper@net-space.pl, ps@pks.im Date: Fri, 5 Aug 2022 11:43:51 +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: <20220805000051.501b7e35@crass-HP-ZBook-15-G2> Content-Type: multipart/alternative; boundary="----=_NextPart_001_62ece657_2c9b_707ddbdf" Received-SPF: pass client-ip=213.182.54.15; envelope-from=brutser@perso.be; helo=msg-4.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: Fri, 05 Aug 2022 09:44:05 -0000 ------=_NextPart_001_62ece657_2c9b_707ddbdf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable See below. Van: Glenn Washburn Aan: brutser--- via Grub-devel Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers Datum: 05/08/2022 07:00:51 Europe/Paris Cc: brutser@perso.be; =C2=A0=C2=A0=C2=A0dkiper@net-space.pl; =C2=A0=C2=A0=C2=A0ps@pks.im On Thu, 4 Aug 2022 18:56:40 +0200 (CEST) brutser--- via Grub-devel wrote: > More testing done: >=20 > the problem most likely is triggered when encrypting partitions (see all= my other comments to get a better picture). >=20 > I tested encrypting a complete device /dev/sdb with detached header and = this worked fine, no issues, with logical volumes created. Ok, this is progress. It looks like there may be an issue with using partitions. I haven't tested that. >=20 >=20 >=20 > So the problem now is consistent, coreboot, or no coreboot, when encrypt= ing a partition, in my tests /dev/sda2, with a detached header, you cannot = decrypt successfully using cryptomount. >=20 >=20 >=20 > cryptomount -H (hd0,msdos1)/header.bin (hd0,msdos2) What if you do this instead: insmod loopback loopback loop (hd0,msdos2)+ cryptomount -H (hd0,msdos1)/header.bin (loop) Does this give the same error? No, this will work normal, ask the passphrase and decrypt the partition! But when setting linux kernel, this error appears: attempt to read or write outside of disk 'crypto0' >=20 > will ALWAYS result in the error:=20 >=20 >=20 >=20 > "no cryptodisk module can handle this device" >=20 >=20 >=20 > Strange is that it seems to be possible to ignore the partition and simp= ly try to 'decrypt the device', which should not be possible of course, but= it validates the passphrase (as seen below in comments), but >=20 > although it opens a crypto0 slot, this is not usable decrypted data. This is expected behavior. As long as you enter a correct password or use a keyfile that is valid for one of the key slots in the detached header, then it doesn't matter what disk device you give to cryptomount, it will always be decrypted "successfully". But it will not be usable unless it is the right block device. >>> Ok makes sense. You still never answered my question about what exact QEMU commandline options you were using >>> sudo qemu-system-x86_64 -serial stdio -drive file=3D~/disk2.img,format= =3Draw,index=3D0,media=3Ddisk -m 3840 -boot d -M q35 --accel kvm , nor if you'd tried to use the options I suggested for getting the serial output as text.=20 >>> yes I tried, but I still had no idea how to get the output and since t= here was a little progress, I didn't want to spend too much time on it: qemu-system-x86_64: -fw_cfg name=3Detc/sercon-port,string=3D0: warning: ex= ternally provided fw_cfg item names should be prefixed with "opt/" but i guess it makes it much easier if I can copy the debug logs, so maybe= we should make this work, can you explain how i can get the logs more deta= iled? Also, you never put in the debug log message for the read hook in cryptodisk like I asked. >>> yes, I somehow did not read that part, so I will do that right now. Glenn >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Debug logs: https://imgur.com/a/onRBSMd >=20 >=20 >=20 > New comments below. >=20 > See comments below. >=20 >=20 > 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 >=20 > On Tue, 2 Aug 2022 22:49:27 +0200 (CEST) > brutser--- via Grub-devel wrote: >=20 > >=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 j= ob to get this inline response done, sorry for that. >=20 > 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. >=20 > 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. >=20 > Glenn >=20 > >>> Comments: > I think I read all your comments and tried to reply as best as possible. >=20 > I tried the following test to eliminate the coreboot issue >> >=20 > Qemu installation: >=20 > 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 51= 2 --pbkdf pbkdf2 --header /root/header.bin --luks2-metadata-size=3D16k --lu= ks2-keyslots-size=3D512k /dev/sda2 > =C2=A0=C2=A0=C2=A0 cryptsetup luksOpen --header /root/header.bin /dev/sd= a2 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= to finish the encryption >=20 > 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) >=20 > result: error: no cryptodisk module can handle this device. >=20 > >>> New comments: >=20 > Getting closer to a solution here, I was just playing around with it and= suddenly I was asked passphrase when entering this line: > cryptomount -H (hd0,msdos1)/header.bin (hd0) >=20 > or when I tried this in the coreboot setup, I changed to: cryptomount -H= (ahci0,msdos1)/header.bin (ahci0) >=20 > wrong passphrase and I get the correct error and correct passphrase and = I get Slot "0" opened and "ls /" is showing me: (crypto0) >=20 > though it can't handle the logical volume and a simple "ls (crypto0)/" w= ill give error: unknown filesystem. >=20 > But why does it accept (hd0), while we clearly encrypted the 2nd partiti= on /dev/sda2 (hd0,msdos2) ? >=20 > Anyway, hope this helps. >=20 >=20 >=20 > >=20 > > Let me be clear on my testing environment, I was purely testing latest= grub as payload for coreboot, so even on qemu, I am using coreboot for BIO= S 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 j= ust 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), = then you could say me. > > Not that it shouldn't work with coreboot obviously, but if other testi= ng could give more accurate results and debug logs for example, I am willin= g 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 coreb= oot and then i create the encrypted sda2 from the debian expert installer e= tc. > >=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. Tha= t > > 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 i= n > > 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 = testing, 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 ca= n > > 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 th= e commands I wrote earlier: > > >=20 > > >=20 > > >=20 > > > cryptsetup luksFormat --type luks2 -q -h sha512 -s 512 --pbkdf pbkdf= 2 --header /root/header.bin --luks2-metadata-size=3D16k --luks2-keyslots-si= ze=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 sai= d 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 dprint= f): > > > >=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 tha= t > > > 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 scr= eenshots, find them attached. As this is probably something I am doing wron= g, 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 -ser= ial > > > > 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 pu= tting > > > > the line 'grub_dprintf("entering luks_scan");' at the start of the > > > > function luks2_scan in grub-core/disk/luks2.c and then recompiling= and > > > > 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_keyboar= d part_msdos part_gpt at_keyboard cbfs cryptodisk luks2 lvm gcry_rijndael g= cry_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-s= ize=3D16k --luks2-keyslots-size=3D512k /dev/sda1 > > > > > >=20 > > > > > > (where --luks2-metadata-size=3D16k --luks2-keyslots-size=3D512= k is optional, this is just to minimize header size, but I also tested with= out). > > > > > >=20 > > > > > > 3. from the grub cmd, i try to decrypt this partition using: c= ryptomount -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= verifying the patches and would expect this to be working, so if yes, this= seems like a bug. > > > > >=20 > > > > > This feature should be working in all cases, and if not there ma= y 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 t= he 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 s= end a > > > > > log of the serial output when the GRUB envvar debug is set to "a= ll" > > > > > while running the cryptomount command? If so, please send compre= ssed in > > > > > a reply to this email on the list. > > > > >=20 > > > > > If you can't because of hardware issues, would you be able to re= plicate > > > > > this in QEMU and grab the serial output from there? If you can b= oot 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 filesystem conta= ining > > > > > 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 >=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_62ece657_2c9b_707ddbdf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable See below.


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

On Thu, 4 Aug 2022 18:56:40 +0200 (CEST)
brutser--- via Grub-devel <grub-devel@gnu.org> wrote:

> More testing done:
>
> the problem most likely is triggered when encrypting partitions (see = all my other comments to get a better picture).
>
> I tested encrypting a complete device /dev/sdb with detached header a= nd this worked fine, no issues, with logical volumes created.

Ok, this is progress. It looks like there may be an issue with using
partitions. I haven't tested that.

>
>
>
> So the problem now is consistent, coreboot, or no coreboot, when encr= ypting a partition, in my tests /dev/sda2, with a detached header, you cann= ot decrypt successfully using cryptomount.
>
>
>
> cryptomount -H (hd0,msdos1)/header.bin (hd0,msdos2)

What if you do this instead:

insmod loopback
loopback loop (hd0,msdos2)+
cryptomount -H (hd0,msdos1)/header.bin (loop)

Does this give the same error?

No, this will work normal, ask the p= assphrase and decrypt the partition!

But when setting linux kernel, = this error appears:
attempt to read or write outside of disk 'crypto0'
>
> will ALWAYS result in the error:
>
>
>
> "no cryptodisk module can handle this device"
>
>
>
> Strange is that it seems to be possible to ignore the partition and s= imply try to 'decrypt the device', which should not be possible of course, = but it validates the passphrase (as seen below in comments), but
>
> although it opens a crypto0 slot, this is not usable decrypted data.<= br>
This is expected behavior. As long as you enter a correct password or
use a keyfile that is valid for one of the key slots in the detached
header, then it doesn't matter what disk device you give to
cryptomount, it will always be decrypted "successfully". But it = will
not be usable unless it is the right block device.

>>> Ok = makes sense.

You still never answered my question about what exact QEMU commandline
= options you were using

>>> sudo qemu-system-x86_64 -serial= stdio -drive file=3D~/disk2.img,format=3Draw,index=3D0,media=3Ddisk -m 384= 0 -boot d -M q35 --accel kvm

, nor if you'd tried to use the options= I
suggested for getting the serial output as text.

>>> yes = I tried, but I still had no idea how to get the output and since there was = a little progress, I didn't want to spend too much time on it:
qemu-syst= em-x86_64: -fw_cfg name=3Detc/sercon-port,string=3D0: warning: externally p= rovided fw_cfg item names should be prefixed with "opt/"
but i= guess it makes it much easier if I can copy the debug logs, so maybe we sh= ould make this work, can you explain how i can get the logs more detailed?<= br>
Also, you never put in
the debug log message for the read hook in cryptodisk like I asked.
>>> yes, I somehow did not read that part, so I will do that righ= t now.

Glenn

>
>
>
>
>
>
>
> Debug logs: https://imgur.com/a/onRBSMd
>
>
>
> New comments below.
>
> 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 my
> > replies? And not top-post, which is posting at the top.
> >
> > I will reply here, though my mail client is not really doing a g= reat 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 dow= n.
> Please look at the full email until you see my name, which indicates<= br> > 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 n= ow.
>
> 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 possib= le.
>
> 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 -= -luks2-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 scri= pts to 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.
>
> >>> New comments:
>
> Getting closer to a solution here, I was just playing around with it = and suddenly I was asked passphrase when entering this line:
> cryptomount -H (hd0,msdos1)/header.bin (hd0)
>
> or when I tried this in the coreboot setup, I changed to: cryptomount= -H (ahci0,msdos1)/header.bin (ahci0)
>
> wrong passphrase and I get the correct error and correct passphrase a= nd I get Slot "0" opened and "ls /" is showing me: (cry= pto0)
>
> though it can't handle the logical volume and a simple "ls (cryp= to0)/" will give error: unknown filesystem.
>
> But why does it accept (hd0), while we clearly encrypted the 2nd part= ition /dev/sda2 (hd0,msdos2) ?
>
> Anyway, hope this helps.
>
>
>
> >
> > Let me be clear on my testing environment, I was purely testing = latest grub as payload for coreboot, so even on qemu, I am using coreboot f= or BIOS 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 my own setup, so if you wanted me to test more general (for example wit= hout coreboot), then 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.
> >
> > 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 coreboot and then i create the encrypted sda2 from the debian expert in= staller 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 very
> > limited"? You've proven capable of modifying the source cod= e to add
> > debug log messages and successfully reproducing the issue in QEM= U. That
> > makes your testing ability not very limited in my opinion. What = am I
> > missing that you're wanting to convey here?
> >
> > 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 n= ot a
> > relevant factor here. What exactly was the QEMU commandline you = used in
> > getting the output you previously created? Did you ever try to g= et the
> > serial output with the QEMU options I suggested previously?
> >
> > >
> > > If you got suggestions with this setup, how i can do anothe= r 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
> > modify the source code of GRUB and run that modified GRUB in QEM= U. 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 res= ponse?
> > I'm starting to think there is an issue in the hook mechanism, b= ut 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<= br> > > > 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 a= sked
> > for the architecture and endianness. For example, are you runnin= g on
> > x86_64 or i386 (64-bit vs 32-bit) x86 architecture? These are al= ways
> > little endian. But you could be running on a MIPS architecture t= hat can
> > be either big or little endian. I want this confirmed so I can g= et the
> > full picture. I'm doubting now that this is important, but you n= ever
> > know.
> >
> > 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 w= ell?
> > Are you running QEMU for testing on that machine as well?
> >
> > I haven't tried to reproduce this issue locally yet due to time<= br> > > 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= enter the commands I wrote earlier:
> > >
> > >
> > >
> > > cryptsetup luksFormat --type luks2 -q -h sha512 -s 512 --pb= kdf pbkdf2 --header /root/header.bin --luks2-metadata-size=3D16k --luks2-ke= yslots-size=3D512k /dev/sda2
> > >
> > > cryptsetup luksOpen --header /root/header.bin /dev/sda2 sda= 2crypt
> > >
> > > 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<= br> > > > 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 scan is
> > > happening. Based on the output I think luks2_read_header mu= st be
> > > failing. That means that either disk reads are failing, whi= ch doesn't
> > > seem like the case, the disk read hook is failing or the LU= KS2 magic
> > > 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 runn= ing
> > > cryptsetup on and what is it for the one GRUB is running on= ?
> > >
> > > 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.
> > >
> > > Glenn
> > >
> > > >
> > > >
> > > >
> > > > Van: Glenn Washburn <development@efficientek.com>= ;
> > > > Aan: brutser--- via Grub-devel <grub-devel@gnu.org&= gt;
> > > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached hea= ders
> > > > 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> w= rote:
> > > >
> > > > > Glenn,
> > > > >
> > > > >
> > > > >
> > > > > As I had no idea how to get the debug logs from q= emu, 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 targ= et. For i386
> > > > using seabios, use "-fw_cfg name=3Detc/sercon-por= t,string=3D0 -serial
> > > > stdio".
> > > >
> > > > 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 putting
> > > > the line 'grub_dprintf("entering luks_scan")= ;' at the start of the
> > > > function luks2_scan in grub-core/disk/luks2.c and then= recompiling and
> > > > getting the output?
> > > >
> > > > Glenn
> > > >
> > > >
> > > > >
> > > > > Van: Glenn Washburn <development@efficientek.c= om>
> > > > > Aan: brutser@perso.be
> > > > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detache= d 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
> > > > >
> > > > > 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= : ahci usb_keyboard part_msdos part_gpt at_keyboard cbfs cryptodisk luks2 l= vm gcry_rijndael gcry_sha1 gcry_sha256 gcry_sha512
> > > > > >
> > > > > > 2. encrypt a partition: cryptsetup luksForma= t --type luks2 -q -h sha512 -s 512 --pbkdf pbkdf2 --header /path/to/header = --luks2-metadata-size=3D16k --luks2-keyslots-size=3D512k /dev/sda1
> > > > > >
> > > > > > (where --luks2-metadata-size=3D16k --luks2-k= eyslots-size=3D512k is optional, this is just to minimize header size, but = I also tested without).
> > > > > >
> > > > > > 3. from the grub cmd, i try to decrypt this = partition using: cryptomount -H /path/to/header (ahci0,msdos1)
> > > > > >
> > > > > >
> > > > > >
> > > > > > 4. I also tried luks1 encryption with detach= ed header.
> > > > > >
> > > > > >
> > > > > >
> > > > > > whatever I try, I always get the same error:=
> > > > > >
> > > > > > "no cryptodisk module can handle this d= evice"
> > > > > >
> > > > > >
> > > > > >
> > > > > > Is this feature not 100% implemented yet, I = saw people already verifying the patches and would expect this to be workin= g, so if yes, this seems like a bug.
> > > > >
> > > > > This feature should be working in all cases, and = if not there may be a
> > > > > bug. I responded to your off-list email before se= eing this one. I'll
> > > > > repeat what I said there and let's continue this = discussion on the list.
> > > > >
> > > > > I see nothing obviously wrong with what you're do= ing, given the
> > > > > information above. To further debug this, would y= ou be able to send a
> > > > > log of the serial output when the GRUB envvar deb= ug is set to "all"
> > > > > while running the cryptomount command? If so, ple= ase send compressed in
> > > > > a reply to this email on the list.
> > > > >
> > > > > If you can't because of hardware issues, would yo= u be able to replicate
> > > > > this in QEMU and grab the serial output from ther= e? 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 f= ilesystem containing
> > > > > the header file).
> > > > >
> > > > > Glenn
> > > > >
> > > > >
> > > > > _______________________________________________ > > > > > Grub-devel mailing list
> > > > > Grub-devel@gnu.org
> > > > > https://lists.gnu.org/mailman/list= info/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=
> >
>
> _______________________________________________
> 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_62ece657_2c9b_707ddbdf--