On Tue, 28 Jun 2022 21:07:47 +0000 Maxim Fomin <ma...@fomin.one> wrote:
> ------- Original Message ------- > On Tuesday, June 28th, 2022 at 5:46 PM, Glenn Washburn > <developm...@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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
