Does systemd-homed require changes for larger sector sizes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi All,

After I took a look at systemd-sysupdate under #28795 to fix sector size assumptions I found that systemd-homed may also suffer from the same fate for LUKS. Can someone please correct my assumptions below?

1. If the LUKS volume is stored as a file under /home then a container with a GPT partition table and a single file partition is created. The LUKS volume and file system is on top of the partition. The LUKS volume has a sector size set but the code currently sets the partition sector size as 512 bytes.

2. If the LUKS volume is stored on a regular block device then I __think__ a GPT partition table is created or at least expected similar to the case above. The backing device could possibly use a different sector size than 512 bytes even if it is unlikely.

@Winterhuman posted the following from https://gitlab.com/cryptsetup/cryptsetup/-/issues/585 about using different sector sizes than the underlying block device.

"If you use 4096-bytes encryption sectors, the whole device must be multiple of it. Kernel dm-crypt cannot process partial-sectors encryption." And moreover, the issue comments mention that certain devices have "off-by-one" sector count issues which might complicate things.

If a user decides to set the --luks-sector-size option then some verification might need to be done. The sector size of the GPT image and the loopback likely needs to be adjusted for case 1. If my assumptions for case 2 hold then an error might be best. Let's see what we get to and I'll attempt a PR.

Thank you,
Michael A Cassaniti
NSW, Australia

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux