From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oIx63-0008FS-NG for mharc-grub-devel@gnu.org; Tue, 02 Aug 2022 14:58:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42808) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIx61-0008Ea-RE for grub-devel@gnu.org; Tue, 02 Aug 2022 14:58:25 -0400 Received: from mail-qt1-x82f.google.com ([2607:f8b0:4864:20::82f]:36611) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oIx5z-0000R0-K8 for grub-devel@gnu.org; Tue, 02 Aug 2022 14:58:25 -0400 Received: by mail-qt1-x82f.google.com with SMTP id h22so11039969qta.3 for ; Tue, 02 Aug 2022 11:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficientek-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc; bh=NG10J05SJ4lQaF+iWInNGk1R+yL26lP77U5aJaaELY4=; b=VYfX/jtK7uTrvBSz/ZYAA3fqq00Ue4BFRxfRG81J9iPCeM4N+TKUXs/c5GSltqgBEO +qKMwiACwFa1Xxu4SgLzzSOLmL6I/P3MM0UV9lOGgAA0G9EMO34wtWRairlgHzWOFwiR aR/DfCppcgu73958/E6ZLSbQF4Woz9JO/t/iP0XpLXUVjvWPQ5gDdlOQkem/B00T23J0 GTQBfu7L4VvvCFWB/uoMiz553gFclbJGUa7oDv+1cYjvp8xbI+eoIdPL7PKXM0Sgieqo hi9thgaK6FyvT3lcTLdBO6BItiMb1vxCK9edO0wh2Xfy6zuZAGWOafTHBO+5vkP0E6Uq QvuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc; bh=NG10J05SJ4lQaF+iWInNGk1R+yL26lP77U5aJaaELY4=; b=Wz/Q3IvOu/7CV2qBAuZqcS6bFJ1Jv6WAgsv0+8C55ZEZ1GPDwXC3QyGLFGzNhfKA/3 encfRLZ3+7uIuqyao4cYTKspKVIahv8hPo2SniFy1nvuTAgmUW4ASEGXQxcRueWXq6Bp QWSngmX39y13n7+xsMETLwhMMMi4s/vaJrdRuQoM8yK9ibk56Pa2SLHhX49ELg/SDMwh wGOFhhtIuJJXkkEWNV4O+AP+JTR5TG1MbdpxtseKjeXXdye1gc5MDF6klFe4KWuTZZfD KJI/rpyf8BqMbPpQu4GQkuBEg7kDW89IX0eIq6GABCeSDjoQ3FQ0MFnwvRd/5zxUTvTt CIFQ== X-Gm-Message-State: AJIora8qL6EIhNNIQxgSKFJUpuEVQ7G58pbNqRbGLdCwYaKldLLJfz3g gJX7GweFmg2qUfSk14HlxcX9GxPpsezWCell X-Google-Smtp-Source: AGRyM1vHt/ejg9ZYjI3X4AVmpiNLW9WwFuHWv/yX9KHKqx43mpZfqeFfEvrVAgA7GOHRd+BcOnL9Iw== X-Received: by 2002:a05:622a:1986:b0:31e:f6c5:2cc9 with SMTP id u6-20020a05622a198600b0031ef6c52cc9mr19484565qtc.358.1659466702126; Tue, 02 Aug 2022 11:58:22 -0700 (PDT) Received: from crass-HP-ZBook-15-G2 ([185.220.103.12]) by smtp.gmail.com with ESMTPSA id v2-20020a05620a440200b006b5e50057basm11217090qkp.95.2022.08.02.11.58.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Aug 2022 11:58:21 -0700 (PDT) Date: Tue, 2 Aug 2022 13:58:17 -0500 From: Glenn Washburn To: brutser--- via Grub-devel Cc: brutser@perso.be, dkiper@net-space.pl, ps@pks.im Subject: Re: [PATCH v3 0/3] Cryptomount detached headers Message-ID: <20220802135817.596d2d97@crass-HP-ZBook-15-G2> In-Reply-To: References: Reply-To: development@efficientek.com X-Mailer: Claws Mail 4.1.0 (GTK 3.24.34; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::82f; envelope-from=development@efficientek.com; helo=mail-qt1-x82f.google.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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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: Tue, 02 Aug 2022 18:58:26 -0000 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. On Tue, 2 Aug 2022 02:26:58 +0200 (CEST) brutser--- via Grub-devel wrote: >=20 >=20 > Glenn, >=20 >=20 >=20 > But my testing is very limited, i only create grub payload for coreboot a= nd then i create the encrypted sda2 from the debian expert installer 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 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? 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 > If you got suggestions with this setup, how i can do another way of testi= ng, 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 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 > 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. 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. =46rom 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? 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 >=20 > as i said, i execute shell during installation, then simply enter the com= mands I wrote earlier: >=20 >=20 >=20 > cryptsetup luksFormat --type luks2 -q -h sha512 -s 512 --pbkdf pbkdf2 --h= eader /root/header.bin --luks2-metadata-size=3D16k --luks2-keyslots-size=3D= 512k /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 bef= ore... >=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 screensh= ots, 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 -serial > > 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 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? > >=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 par= t_msdos part_gpt at_keyboard cbfs cryptodisk luks2 lvm gcry_rijndael gcry_s= ha1 gcry_sha256 gcry_sha512 > > > >=20 > > > > 2. encrypt a partition: cryptsetup luksFormat --type luks2 -q -h sh= a512 -s 512 --pbkdf pbkdf2 --header /path/to/header --luks2-metadata-size= =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 without). > > > >=20 > > > > 3. from the grub cmd, i try to decrypt this partition using: crypto= mount -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 veri= fying the patches and would expect this to be working, so if yes, this seem= s 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 li= st. > > >=20 > > > 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 send compressed = in > > > a reply to this email on the list. > > >=20 > > > If you can't because of hardware issues, would you be able to replica= te > > > this in QEMU and grab the serial output from there? If you can boot t= he > > > 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 containing > > > 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