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

[Maxim Fomin]

------- Original Message -------
On Tuesday, June 28th, 2022 at 5:46 PM, Glenn Washburn 
<development@efficientek.com> wrote:
> The reason that we need '-O', or keyfile offset, is because block
> syntax is for specifying block ranges, not byte ranges. Blocks are
> sized in the native GRUB block size, which is 512 bytes. If we do not
> have '-O', then keyfile data must be aligned on 512-byte boundaries,
> which I think is an unreasonable restriction.

Agreed.

> On the other hand, I don't think that a '-o' option is needed because
> restricting plainmount encrypted data to be 512-byte aligned seems a
> reasonable restriction. If the data is not 512-byte aligned, I suspect
> you're going to get poorer read/write performance. This is maybe not a
> problem for small plainmounts that may contain key material for
> unlocking other volumes. So I'm open to this being a desirable feature,
> and not dead-set against it.
>
> It would be interesting to verify that cryptsetup cannot create a
> LUKS1/LUKS2 volume where the data offset is not 512-byte aligned. I
> think this is true, but the LUKS2 standard has the offset in bytes, so
> its technically possible. If cryptsetup can create a volume where the
> encrypted data is not 512-aligned, then there's a good case for adding
> '-o'.

cryptsetup supports only 512 byte block alignment for LUKS1 and 512-4096 
alignment for LUKS2. Its offset parameter is specified in terms of the number 
of 512 byte blocks.

> > Also, I am thinking whether it will be easier from the user perspective to 
> > support blocklist syntax (without
> > loopback) for device argument too - having the same syntax for device and 
> > offset arguments is more clear.
>
>
> Do you mean "file argument" instead of "device argument" here? Because
> devices already support blocklist syntax.
>
> > However, it will works only if 'grub_file_t' provides interface to 
> > 'grub_disk_t' object which is needed for
> > cryptodisk to read encrypted data. I didn't look at it, but if it works, 
> > the command syntax can be simplified
> > to blocklist syntax for both device and offset argument.
>
>
> I'm not sure I'm understanding this. Can you give some examples of what
> the new command syntax that you're thinking of might look like? How
> would blocklist syntax be used for the offset argument? That sounds
> like it could be confusing.
>
> Glenn
>

I was not saying about some new syntax for some device offset argument.
I am speaking about this:

loopback node (hd0,gpt2)2048+
plainmount node            -c aes-xts-plain64 -h sha512 // works
plainmount (hd0,gpt2)2048+ -c aes-xts-plain64 -h sha512 // currently - no

Currently the second command does not work without loopback, I am thinking 
about removing this limitation in plainmount.

Best regards,
Maxim Fomin