From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1o53py-0003VQ-HT for mharc-grub-devel@gnu.org; Sat, 25 Jun 2022 07:20:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35288) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o53pv-0003Ua-Nk for grub-devel@gnu.org; Sat, 25 Jun 2022 07:20:23 -0400 Received: from mail-40136.proton.ch ([185.70.40.136]:36962) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o53pr-0005K4-Kx for grub-devel@gnu.org; Sat, 25 Jun 2022 07:20:23 -0400 Date: Sat, 25 Jun 2022 11:19:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fomin.one; s=protonmail; t=1656155988; x=1656415188; bh=TRZGFGeLZj3uripY9Hxj6svHFy2qJIO3juBHdiepUGY=; h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=gGqurYZcYubwGC0+UgYi1aAbp/e9BisNdCH9cn534DhGQHnsbf2HNBlsrmXmjuy6T DucZ6V1skIEsIj0/gDU3h5pGQlmbPmhMcXYK/7fEx5NZ5qH3cYnyJjDLmUXvfYia9v X1lFKE3EtSVGjS5m2fqIyUhj/j50w7bXujH+ANaNfTm1FFWMD2PiHY1+MbLQp7UiCI 5KxGnR/DEGTps5bJQxJjAeiSI+2XLLzkXKnayGY2JmAsQyliYUXb0PGCcqxsBOadYk beJ8dmrH7mOUNk+JF7CrscCsOxEpqhUMss1VfFuiJuHX7T2YO44lhh2LdSPdA/aEYz YRNan+tyxbTig== To: "grub-devel@gnu.org" From: Maxim Fomin Reply-To: Maxim Fomin Subject: Re: [PATCH v3 1/1] plainmount: Support plain encryption mode. Message-ID: In-Reply-To: <20220624195541.1bf8fd17@crass-HP-ZBook-15-G2> References: <20220624195541.1bf8fd17@crass-HP-ZBook-15-G2> Feedback-ID: 10594471:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.40.136; envelope-from=maxim@fomin.one; helo=mail-40136.proton.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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: Sat, 25 Jun 2022 11:20:24 -0000 ------- Original Message ------- On Saturday, June 25th, 2022 at 12:55 AM, Glenn Washburn wrote: > > + > > +Offset of encrypted data (device argument) and offset of keyfile (opti= on @option{-d}) > > +can be specified with grub blocklist syntax ('+10M') where single word= suffixes 'K', > > +'M' and 'G' (base 1024) are available. Note: unlike other grub command= s, plainmount > > +supports only single blocklist offset. > > > Hmm, I wasn't suggesting this be added. I hope you didn't think I was > suggesting this. What I was suggesting was that the block list syntax > already supported in GRUB for device paths be used, not creating a new > block list syntax just for this command. You shouldn't need to add any > new code for what I was suggesting. > > For instance, if you know that your plain mount volume is on device > (hd0) at offset 1M and have a keyfile at (hd1)/path/to/keyfile where > the key material is offset 35235 bytes into that file you would use: > > loopback cplain0 (hd0)2048+ > plainmount -c ... -s ... -d (hd1)/path/to/keyfile -O 35235 (cplain0) > > If the keyfile data is on disk (hd1) at offset 16708 (16*1024 + 324), > then use: > > plainmount -c ... -s ... -d (hd1)32+ -O 324 (cplain0) > > or > > plainmount -c ... -s ... -d (hd1)+ -O 16708 (cplain0) > > Here the '+' is needed after (hd1) to turn it into a file because -d > should only take a file. It would be nice to have (hd1) be treated as > (hd1)+ when used as a file, but that would be a different patch. > > The drawback to what I'm suggesting is that you can't do "-d > (hd1)16K+". This could be something interesting to add to GRUB > blocklist syntax, but as a separate patch. > > I believe there's also a confusion here on the usage of blocklist > syntax. Blocklist syntax is about specifying a range of blocks, not an > offset or specific block number. So for instance, "(hd1)+16" means > blocks 0-15, a total of 8K bytes, so bytes past 8K are unreadable. On > the other hand, "(hd1)16+" means blocks 16 to end of device. I think the > latter is what you want. I thought that the blocklist syntax is some specification which is implemen= ted in each command because I didn't use that feature. Now I understand you and wi= ll remove not needed parsing functions mentioned below and resubmit the patch. > > +By default new cryptodisk node will have uuid '109fea84-a6b7-34a8-4bd1= -1c506305a4e1' > > +where last digits are incremented for each subsequently created node. = Custom > > +uuid can be specified with option @option{-u}. > > + > > +The plainmount command can report internal cryptographic errors. If th= ey happen, > > > Its not clear to me what internal cryptographic errors are reported, > under what conditions. I was refering to the possible error in cryptodisk_setkey() function. When = I was debugging first versions of the patch I have noticed that when cipher/key s= ize do not match each other or have invalid values, setkey() returns error. Best regards, Maxim Fomin