[systemd-devel] Does systemd-homed require changes for larger sector sizes

Michael Cassaniti michael at cassaniti.id.au
Tue Aug 15 00:14:44 UTC 2023


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20230815/745b85fc/attachment.sig>


More information about the systemd-devel mailing list