From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oIeEQ-0001mC-Vz for mharc-grub-devel@gnu.org; Mon, 01 Aug 2022 18:49:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44682) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIeEP-0001m4-Ae for grub-devel@gnu.org; Mon, 01 Aug 2022 18:49:49 -0400 Received: from mail-qt1-x835.google.com ([2607:f8b0:4864:20::835]:42792) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oIeEH-0001fa-EA for grub-devel@gnu.org; Mon, 01 Aug 2022 18:49:49 -0400 Received: by mail-qt1-x835.google.com with SMTP id w29so9192948qtv.9 for ; Mon, 01 Aug 2022 15:49:40 -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=3SJU3aCO4MVjsJh5SI5WWcEVBolSmzOMKBYeSOyi7g0=; b=mhdgyLJcOySC7sKy6roiGIJO2XdGAx896sDoYU8kNpaeJ0XmAe6hPOZy4lKXkWoO28 xEB7y5TUUq0XwuJdbFO2kAH77gxkxwniVONdUww5yxtWaB9t58w72Yv6OcN6RKYOVrnp 6KZPvt60SoYeDQL70hPqImdJfHCueOfk1ChKG/NnVBZaKjlHoEZvs/YF/kLK9lzRFGa9 iqDQPoMfWD3fknhMAWRcEcY7aV6COQXCMQnafffchtCqYXHf9PIWnj6VOwhVK6F6j7q0 HJvXMyOYhCdHi3e78KWVMKTHPASE9M7ppZ2roBWVYxbKv40tfl8IfDxnL/fR+a+6Qnzs Ye+w== 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=3SJU3aCO4MVjsJh5SI5WWcEVBolSmzOMKBYeSOyi7g0=; b=Yycp+Z0cmb6pmeA1xN+M5nKlHK2p0lRU0eqI7YlR7jKktbEmal7T+m7vxk9OJUpqg6 paENiyebnbG2KoRnbhiwJ916gkDKLiOv0Gy2+G3ecObWSu5rRF7Q+mZv9OlTe2zEgPjx xLrEp37A0ykznNgriuzU4Qnpe6n+437dw1cMDZySqrkYYk+yhi9Wcfvc4bSCLq+W3sqS x7ecJ0kj+mxO8jeY5xbtuV9ekl7jGCNsKQCP6oZrx3ht38HrY6ER9NsflZClPd0KlVsZ jUPF498GMs2vv9q2F0kozLMzyqtGmUrk05QBw6lOLkIkKYLF2u6A8PnWCQp/941hH2r2 YQiQ== X-Gm-Message-State: AJIora9w1/TlzJAWkFzT+inH3zSC9Bk3wi72diLJMMXcdPsdWfSlCOA3 C8scwYuJRHuogodXLgWs2L0eQ3k3h7WPWwGs X-Google-Smtp-Source: AGRyM1u6ngvAwpq1SivN9Cg++AlMa/KCsUJZq0OAKurWA/fi5nmjLDaR5GTA6P1ZQy+x8MTNe8CI6g== X-Received: by 2002:ac8:7f91:0:b0:31e:fec2:eb18 with SMTP id z17-20020ac87f91000000b0031efec2eb18mr16151257qtj.485.1659394180101; Mon, 01 Aug 2022 15:49:40 -0700 (PDT) Received: from crass-HP-ZBook-15-G2 ([185.220.103.12]) by smtp.gmail.com with ESMTPSA id p4-20020ac84084000000b0031ecb762677sm8020784qtl.66.2022.08.01.15.49.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Aug 2022 15:49:40 -0700 (PDT) Date: Mon, 1 Aug 2022 17:49:34 -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: <20220801174934.2e4b6df1@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::835; envelope-from=development@efficientek.com; helo=mail-qt1-x835.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, 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: Mon, 01 Aug 2022 22:49:49 -0000 On Sat, 30 Jul 2022 20:48:54 +0200 (CEST) brutser--- via Grub-devel wrote: > Glenn, >=20 >=20 >=20 > The most obvious error that jumps out:=20 >=20 > Read out of range: sector 0x32000 (attempt to read or write outside parti= tion) This looks like a red-herring to me. I believe it happens because in opening the header file the disk is probed to see what file system is on it. The error occurs in the probe for cbfs, which fails because its an ext* filesystem. Glenn >=20 >=20 > Van: brutser--- via Grub-devel > Aan: grub-devel@gnu.org > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers > Datum: 30/07/2022 11:54:32 Europe/Paris > Cc: brutser@perso.be; > =C2=A0=C2=A0=C2=A0dkiper@net-space.pl; > =C2=A0=C2=A0=C2=A0ps@pks.im >=20 > Glenn, >=20 >=20 >=20 > 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. >=20 >=20 >=20 > https://imgur.com/a/rAlfZ77 >=20 >=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_ms= dos part_gpt at_keyboard cbfs cryptodisk luks2 lvm gcry_rijndael gcry_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-size=3D16k= --luks2-keyslots-size=3D512k /dev/sda1 > >=20 > > (where --luks2-metadata-size=3D16k --luks2-keyslots-size=3D512k is opti= onal, 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: cryptomoun= t -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 verifyin= g the patches and would expect this to be working, so if yes, this seems li= ke 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 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 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 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 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >=20