mirror of
https://git.proxmox.com/git/grub2
synced 2025-07-21 00:06:35 +00:00
![]() By default, dm-crypt internally uses an IV that corresponds to 512-byte sectors, even when a larger sector size is specified. What this means is that when using a larger sector size, the IV is incremented every sector. However, the amount the IV is incremented is the number of 512 byte blocks in a sector (i.e. 8 for 4K sectors). Confusingly the IV does not correspond to the number of, for example, 4K sectors. So each 512 byte cipher block in a sector will be encrypted with the same IV and the IV will be incremented afterwards by the number of 512 byte cipher blocks in the sector. There are some encryption utilities which do it the intuitive way and have the IV equal to the sector number regardless of sector size (ie. the fifth sector would have an IV of 4 for each cipher block). And this is supported by dm-crypt with the iv_large_sectors option and also cryptsetup as of 2.3.3 with the --iv-large-sectors, though not with LUKS headers (only with --type plain). However, support for this has not been included as grub does not support plain devices right now. One gotcha here is that the encrypted split keys are encrypted with a hard- coded 512-byte sector size. So even if your data is encrypted with 4K sector sizes, the split key encrypted area must be decrypted with a block size of 512 (ie the IV increments every 512 bytes). This made these changes less aesthetically pleasing than desired. Signed-off-by: Glenn Washburn <development@efficientek.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> |
||
---|---|---|
.. | ||
arc | ||
efi | ||
i386/pc | ||
ieee1275 | ||
uboot | ||
xen | ||
AFSplitter.c | ||
ahci.c | ||
ata.c | ||
cryptodisk.c | ||
diskfilter.c | ||
dmraid_nvidia.c | ||
geli.c | ||
host.c | ||
ldm.c | ||
loopback.c | ||
luks2.c | ||
luks.c | ||
lvm.c | ||
mdraid1x_linux.c | ||
mdraid_linux_be.c | ||
mdraid_linux.c | ||
memdisk.c | ||
pata.c | ||
raid5_recover.c | ||
raid6_recover.c | ||
scsi.c | ||
usbms.c |