System encryption pretest fails with "The parameter is incorrect"...
Open source disk encryption with strong security for the Paranoid
Brought to you by:
idrassi
Menu
▾
▴
Summary
System encryption pretest fails on a Lenovo ThinkPad X1 Carbon Gen 14 with
"The parameter is incorrect. Source: VeraCrypt::File::Write:959" (1.26.24)
and "VeraCrypt::File::Write:1024" (1.26.29).
The root cause appears to be buffer alignment: the NVMe drive / stornvme
reports AlignmentMask = 0xF (16-byte), and Windows rejects raw disk I/O
whose buffer address is not 16-byte aligned with ERROR_INVALID_PARAMETER (87).
Most drives report AlignmentMask = 0x3 (4-byte), which is why the issue
does not appear on other hardware.
Environment
Reproduction
Diagnostics
Process Monitor: VeraCrypt Format.exe opens \Device\Harddisk0\DR0 for
Read/Write, then closes it ~240 ms later with no WriteFile logged, and rollback
starts immediately. The write is rejected by the I/O manager before an IRP
reaches the storage stack, which is consistent with an alignment check.
A read-only test (attached script) querying IOCTL_STORAGE_QUERY_PROPERTY
(StorageAdapterProperty) and reading 4096 bytes from \.\PhysicalDrive0
with different buffer offsets from a page-aligned base:
AlignmentMask=0xF MaxTransfer=262144 MaxPhysPages=513 BusType=17 (NVMe)
buffer offset 0 -> OK
buffer offset 4 -> ERROR 87
buffer offset 8 -> ERROR 87
buffer offset 12 -> ERROR 87
buffer offset 16 -> OK
buffer offset 32 -> OK
buffer offset 64 -> OK
buffer offset 76 -> ERROR 87
buffer offset 80 -> OK
buffer offset 512 -> OK
Same result with and without FILE_FLAG_NO_BUFFERING.
Our analysis suggests the buffer passed to WriteFile in File::Write is a
member inside a larger object, landing at offset 76 (4-byte aligned but
not 16-byte aligned).
Disabling VBS/HVCI/System Guard and Secure Boot made no difference.
Suggested fix
Allocate buffers used for raw device I/O with explicit alignment
(e.g. _aligned_malloc / VirtualAlloc, or align to at least the device
AlignmentMask + 1 / sector size), or copy into an aligned bounce buffer
in File::Write / File::Read before calling WriteFile / ReadFile.
Possibly related
Older reports with the same error at different line numbers, never resolved:
Newer NVMe drives/platforms reporting 16-byte alignment may make this
more common going forward.
Update: second affected machine (UFS storage, 4K sectors)
Tested a second machine with a different vendor, storage type and controller.
The same buffer alignment issue is present, plus a 4K sector size.
Environment
VeraCrypt error on this machine: [PASTE ERROR TEXT HERE]
Alignment test (same read-only script as above)
AlignmentMask=0x7 MaxTransfer=524288 MaxPhysPages=64 BusType=19 (UFS)
buffer offset 0 -> OK
buffer offset 4 -> ERROR 87
buffer offset 8 -> OK
buffer offset 12 -> ERROR 87
buffer offset 16 -> OK
buffer offset 76 -> ERROR 87
buffer offset 80 -> OK
Same result with and without FILE_FLAG_NO_BUFFERING.
This controller requires 8-byte alignment rather than 16-byte, but offset 76
still fails (76 mod 8 = 4). Any buffer that is only 4-byte aligned fails on
both machines.
Second blocker: 4Kn logical sectors
The drive reports 4096-byte logical sectors. As far as I understand,
VeraCrypt system encryption requires 512-byte logical sectors. UFS devices
cannot be reformatted to 512-byte LBA, so this machine cannot be
system-encrypted even if the alignment issue is fixed. Can you confirm 4Kn
support status for system encryption, and whether it is planned?
DiskCryptor fails too
DiskCryptor 2.0.1 pre-release fails on the same machine when starting
encryption of C: with "Error start encrypt volume [C:] Error: read/write error".
I have not traced the cause there, but it suggests the problem is not unique
to VeraCrypt: either 4Kn sectors or the stricter alignment breaks raw disk I/O
in other disk encryption tools as well.
Summary
Controllers that require more than 4-byte alignment are becoming common on
new platforms (NVMe and UFS). Aligning raw I/O buffers to at least the sector
size (e.g. _aligned_malloc / VirtualAlloc) would cover both cases.