[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: |
Tue, 28 Jun 2022 21:07:47 +0000 |
------- 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