Description of problem: https://fedoraproject.org/wiki/Changes/LUKSEncryptionSectorSize This says the *physical* sector needs to be 4096 bytes. But when I run luksFormat on a 512/4096 byte sector drive, the LUKS header shows 512 bytes. I'm not sure if it's expected? Or if the intent is to use LUKS 4096 bytes only when the drive reports 4096 logical byte sector? Version-Release number of selected component (if applicable): Fedora-Workstation-Live-x86_64-Rawhide-20220119.n.0.iso cryptsetup-2.4.3-1.fc36.x86_64 libblockdev-2.26-1.fc35.x86_64 How reproducible: Reproduces on both Fedora 35 and 36 Steps to Reproduce: 1. qemu-kvm is setup with virtio test drive <blockio logical_block_size="512" physical_block_size="4096"/> 2. cryptsetup luksformat /dev/vdb 3. cryptsetup luksDump /dev/vdb Actual results: Data segments: 0: crypt offset: 16777216 [bytes] length: (whole device) cipher: aes-xts-plain64 sector: 512 [bytes] Expected results: It should be 4096 bytes? Additional info: [root@fedora ~]# blockdev --getbsz /dev/vdb 4096 [root@fedora ~]# blockdev --getpbsz /dev/vdb 4096 [root@fedora ~]# blockdev --getss /dev/vdb 512 Separate from this bug, I guess a big problem is that most NVMe out there are lying about their physical sector size anyway, so they unfortunately won't get the feature change in any case. But for devices that report 512/4096 sector size, it seems safe enough to use 4096 byte sector size for LUKS. In fact I'm using 4096 sector size for LUKS on a physical drive that reports 512/512 via an enclosure that is likewise lying about physical sector size, the drive in the enclosure is 512e thus 4096 byte physical sector.
Also related bug 2044108
We need --debug output form luksFormat command that created the LUKS2 container. You're right that in general 4096/512e drives should have been properly formated with 4KiB encryption sector size (and the features works exactly like this). Also if it's really related to bug #2044108, luksFormat just falls back to 512 bytes. We can not fix misaligned partitions.
When I luksFormat the whole /dev/vdb device I get a 4096 byte LUKS sector size. When I partition it, I don't. The partition is aligned, it starts at LBA 2048. Every sector is 4K aligned. It's just that there's 7 dangling 512-byte sectors instead of 8, so the last "sector" is just short of 4096 bytes. That seems to be the problem. And I don't know whose bug that is because it's going to be really common with 512e drives. gdisk, fdisk, and parted all do it this way. Is there any way cryptsetup can just map out the last 1-7 sectors and not fail? [root@fedora ~]# blockdev --getsize64 /dev/vdb1 107373116928 [root@fedora ~]# cryptsetup --debug luksFormat /dev/vdb1 # cryptsetup 2.4.3 processing "cryptsetup --debug luksFormat /dev/vdb1" # Running command luksFormat. # Locking memory. # Installing SIGINT/SIGTERM handler. # Unblocking interruption on signal. # Allocating context for crypt device /dev/vdb1. # Trying to open and read device /dev/vdb1 with direct-io. # Initialising device-mapper backend library. WARNING! ======== This will overwrite data on /dev/vdb1 irrevocably. Are you sure? (Type 'yes' in capital letters): YES # Interactive passphrase entry requested. Enter passphrase for /dev/vdb1: Verify passphrase: # Checking new password using default pwquality settings. # New password libpwquality score is 90. # Crypto backend (OpenSSL 3.0.0 7 sep 2021 [default][legacy]) initialized in cryptsetup library version 2.4.3. # Detected kernel Linux 5.17.0-0.rc0.20220112gitdaadb3bd0e8d.63.fc36.x86_64 x86_64. # Only 2 active CPUs detected, PBKDF threads decreased from 4 to 2. # PBKDF argon2id, time_ms 2000 (iterations 0), max_memory_kb 1048576, parallel_threads 2. # Formatting device /dev/vdb1 as type LUKS2. # Auto-detected optimal encryption sector size for device /dev/vdb1 is 4096 bytes. # dm version [ opencount flush ] [16384] (*1) # dm versions [ opencount flush ] [16384] (*1) # Detected dm-ioctl version 4.45.0. # Device-mapper backend running with UDEV support enabled. # Topology: IO (4096/0), offset = 0; Required alignment is 1048576 bytes. # Device size is not aligned to sector size. Reverting to 512 bytes. # Checking if cipher aes-xts-plain64 is usable. # Using userspace crypto wrapper to access keyslot area. # Formatting LUKS2 with JSON metadata area 12288 bytes and keyslots area 16744448 bytes. # Creating new digest 0 (pbkdf2). # Setting PBKDF2 type key digest 0. # Running pbkdf2(sha256) benchmark. # PBKDF benchmark: memory cost = 0, iterations = 668734, threads = 0 (took 49 ms) # PBKDF benchmark: memory cost = 0, iterations = 903944, threads = 0 (took 580 ms) # Benchmark returns pbkdf2(sha256) 903944 iterations, 0 memory, 0 threads (for 512-bits key). # Segment 0 assigned to digest 0. # Wiping LUKS areas (0x000000 - 0x1000000) with zeroes. # Wiping keyslots area (0x008000 - 0x1000000) with random data. # Reusing open rw fd on device /dev/vdb1 # Device size 107373116928, offset 16777216. # Acquiring write lock for device /dev/vdb1. # Opening lock resource file /run/cryptsetup/L_252:17 # Verifying lock handle for /dev/vdb1. # Device /dev/vdb1 WRITE lock taken. # Trying to write LUKS2 header (16384 bytes) at offset 0. # Reusing open rw fd on device /dev/vdb1 # Checksum:e0c1f449aa1a9a23150ac52ce3be69c35a659afa654bb1f6f908d6ad60a18706 (in-memory) # Trying to write LUKS2 header (16384 bytes) at offset 16384. # Reusing open rw fd on device /dev/vdb1 # Checksum:666c56e456f8349bb7b4ed054168de20281c2dbd6c01117917b5fa3184552956 (in-memory) # Device /dev/vdb1 WRITE lock released. # Adding new keyslot -1 using volume key. # Adding new keyslot -1 with volume key assigned to a crypt segment. # Selected keyslot 0. # Keyslot 0 assigned to digest 0. # Trying to allocate LUKS2 keyslot 0. # Found area 32768 -> 290816 # Running argon2id() benchmark. # PBKDF benchmark: memory cost = 65536, iterations = 4, threads = 2 (took 218 ms) # PBKDF benchmark: memory cost = 75155, iterations = 4, threads = 2 (took 253 ms) # PBKDF benchmark: memory cost = 594110, iterations = 4, threads = 2 (took 2141 ms) # Benchmark returns argon2id() 4 iterations, 594110 memory, 2 threads (for 512-bits key). # Calculating attributes for LUKS2 keyslot 0. # Acquiring write lock for device /dev/vdb1. # Opening lock resource file /run/cryptsetup/L_252:17 # Verifying lock handle for /dev/vdb1. # Device /dev/vdb1 WRITE lock taken. # Checking context sequence id matches value stored on disk. # Reusing open ro fd on device /dev/vdb1 # Running keyslot key derivation. # Updating keyslot area [0x8000]. # Reusing open rw fd on device /dev/vdb1 # Device size 107373116928, offset 16777216. # Device /dev/vdb1 WRITE lock already held. # Trying to write LUKS2 header (16384 bytes) at offset 0. # Reusing open rw fd on device /dev/vdb1 # Checksum:0f66499ccf7dc4f045342b2d2938efef039fc62fbba9c70da9efbcd01545ea49 (in-memory) # Trying to write LUKS2 header (16384 bytes) at offset 16384. # Reusing open rw fd on device /dev/vdb1 # Checksum:7629c630ae387d9255acd2eb6babd619df5d4f864d0eba2f11bd9d1066234a92 (in-memory) # Device /dev/vdb1 WRITE lock released. Key slot 0 created. # Releasing crypt device /dev/vdb1 context. # Releasing device-mapper backend. # Closing read only fd for /dev/vdb1. # Closing read write fd for /dev/vdb1. # Unlocking memory. Command successful. [root@fedora ~]# cryptsetup luksDump /dev/vdb1 LUKS header information Version: 2 Epoch: 3 Metadata area: 16384 [bytes] Keyslots area: 16744448 [bytes] UUID: ef6e0fc8-a2c3-4faf-ab4f-1da1997a9f54 Label: (no label) Subsystem: (no subsystem) Flags: (no flags) Data segments: 0: crypt offset: 16777216 [bytes] length: (whole device) cipher: aes-xts-plain64 sector: 512 [bytes] Keyslots: 0: luks2 Key: 512 bits Priority: normal Cipher: aes-xts-plain64 Cipher key: 512 bits PBKDF: argon2id Time cost: 4 Memory: 594110 Threads: 2 Salt: 49 bb e4 65 52 0e e9 8b dc 73 5b 80 e1 c7 e9 2b bf 2b 5c 0d 6c b3 62 df 6e 1f e6 e9 92 7e 4f 56 AF stripes: 4000 AF hash: sha256 Area offset:32768 [bytes] Area length:258048 [bytes] Digest ID: 0 Tokens: Digests: 0: pbkdf2 Hash: sha256 Iterations: 112993 Salt: c8 ce 30 21 38 72 40 ee 57 23 5c e0 c1 b3 01 8e 55 98 f9 61 5d 56 44 f0 00 95 36 e3 d6 44 b4 2e Digest: a2 fe 6b 8d e7 8a 3d 7c 27 94 72 a8 6b 4e 24 a6 68 c3 2e 7e c3 57 05 65 71 ce 8b 1a 69 9b f5 30 [root@fedora ~]# gdisk -l /dev/vdb GPT fdisk (gdisk) version 1.0.8 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/vdb: 209715200 sectors, 100.0 GiB Sector size (logical/physical): 512/4096 bytes Disk identifier (GUID): D064C069-451A-4C03-A1CC-19FB2C8F7E97 Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 209715166 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB) Number Start (sector) End (sector) Size Code Name 1 2048 209715166 100.0 GiB 8300 Linux filesystem [root@fedora ~]#
(In reply to Chris Murphy from comment #3) > When I luksFormat the whole /dev/vdb device I get a 4096 byte LUKS sector > size. When I partition it, I don't. The partition is aligned, it starts at > LBA 2048. Every sector is 4K aligned. It's just that there's 7 dangling > 512-byte sectors instead of 8, so the last "sector" is just short of 4096 > bytes. That seems to be the problem. And I don't know whose bug that is > because it's going to be really common with 512e drives. gdisk, fdisk, and > parted all do it this way. Is there any way cryptsetup can just map out the > last 1-7 sectors and not fail? Well, that's the problem. We can not create 4K aligned dm-crypt device on top of partition where length is not aligned to 4K. --debug output complains about it down below: > (snip) > # Auto-detected optimal encryption sector size for device /dev/vdb1 is 4096 > bytes. > # dm version [ opencount flush ] [16384] (*1) > # dm versions [ opencount flush ] [16384] (*1) > # Detected dm-ioctl version 4.45.0. > # Device-mapper backend running with UDEV support enabled. > # Topology: IO (4096/0), offset = 0; Required alignment is 1048576 bytes. > # Device size is not aligned to sector size. Reverting to 512 bytes. This ^^^^ Not sure what to do with it. The problem is that LUKS2 always uses whole device underneath it. It would fail during device activation because last 4K block would be missing (impossible to map properly).
Started a thread on upstream cryptsetup/dm-crypt list: https://marc.info/?l=dm-crypt&m=164306225923513&w=2 I think this bug is notabug. It's clearly working as designed including the fallback. If the design is wrong, the list is probably the better place to discuss it.