[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 1/1] plainmount: Support plain encryption mode.

From: Maxim Fomin
Subject: Re: [PATCH v3 1/1] plainmount: Support plain encryption mode.
Date: Sat, 25 Jun 2022 11:19:44 +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 (option 
> > @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 commands, 
> > 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 implemented 
each command because I didn't use that feature. Now I understand you and will
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 they 
> > 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 size
do not match each other or have invalid values, setkey() returns error.

Best regards,
Maxim Fomin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]