------- 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. > > 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
