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

[Glenn Washburn]

On Tue, 28 Jun 2022 21:07:47 +0000
Maxim Fomin <maxim@fomin.one> wrote:

> ------- 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.

The LUKS1 payload offset is in 512-byte sectors. However, the LUKS2
segment offset is in _bytes_[1]. So my point still stands.

[1]
https://fossies.org/linux/cryptsetup/docs/on-disk-format-luks2.pdf#subsection.3.3

> > > 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.

Ahh, yes, that does not work. Instead of removing this limitation for
plainmount, I think it would be better to remove this limitation for
all instances where devices are given to commands. Basically allow
grub_device_open to open blocklist syntax. Without much research, I
think this would entail adding an offset grub_disk_t and refactoring
grub_fs_blocklist_open() to use a common function that does the block
list parsing and that can then be reused in grub_disk_open(). I do not
really like the idea of having this as a special case for plainmount.

Glenn

> 
> Best regards,
> Maxim Fomin
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel