From the VeraCrypt documentation link: "VeraCrypt does not block the trim operation on partitions that are within the key scope of system encryption"
From this statement, it sounds like both FDE and System Partition Encryption would allow TRIM passthrough.
I did the following steps, but could not get TRIM to work on an encrypted system partition.
1) Created a 200GB partition on a new 256GB SSD.
2) Installed Win 7 Pro x64 (legacy bios mode) on the 200GB partition.
3) Booted into Windows and verified TRIM was activated via "fsutil behavior query DisableDeleteNotify".
4) Ran TrimCheck and verified TRIM was working.
5) Used HxD Hex Editor to view raw disk sectors to verify unused sectors were still zeroed.
6) Installed VeraCrypt and encrypted the 200GB System Partition only (not entire drive). Encryption was successful.
7) Rebooted and verified with HxD Hex Editor that all sectors, including previous zeroed sectors, now contained data.
8) Verified TRIM was still activated via "fsutil behavior query DisableDeleteNotify".
9) Ran TrimCheck again, but now TRIM is not working.
10) Tried to do a manual TRIM with SSDTool, but didn't work.
11) Tried to do a manual TRIM with ForceTrim, but didn't work.
Does anyone have any advice or experience with TRIM working on an encrypted system partition?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just wanted to second the post above. I had pretty much the exact same experience just now. Have you found a fix yet? I was wondering if maybe the drive needs to be set to AHCI in the BIOS before the Windows install, but I don't even have that option in the BIOS, even though this is a new laptop. On the other hand, if AHCI was the issue, then why did TrimCheck work before the encryption? I also tried the following VeraCrypt feature, to no avail: "Enable extended disk control codes support".
This is pretty frustrating, as it leads me to believe that VeraCrypt is a no-go for SSDs afterall. Notice the careful wording saying it "does not block" trim operation, instead of actually positively stating that it will indeed pass-through the trim operations. I now turn to my frenemy, Bitlocker. :(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have run sevral tests using system encryption with SSD under Windows 10 and I didn't see any issue with TRIM. TRIM commands are received by VeraCrypt driver and they are transfered correctly to the SSD. So TRIM support for system encryption is still OK and the documentation is valid.
I believe you were mislead by the fact that both tools TrimCheck and HxD return data that are different from what is stored on disk because VeraCrypt intercept there I/O and the data returned is the result of decryption of what is stored on the disk.
For TrimCheck, it will conclude that TRIM status is INDETERMINATE because the data it reads is not zeros but actually the data returned is the result of the decryption of zeros which are actually stored on the disk! To convince yourself, run TrimCheck 4 times in a row so that he uses the same disk position for its tests and you will notice that the data he reads is always the same although it is writing random data each time.
For HxD, the same thing happens: the data it reads are the result of the decryption done transparently by VeraCrypt and not what is really stored on the physical drive. That's why HxD does not display zeroes and it displays data that is the result of the decryption of zeros!
I didn't run the tools SSDTool and ForceTrim but clearly they are affected the same way as TrimCheck since they can not read the zeros stored on the SSD and they get decryption output of VeraCrypt instead.
So, if VeraCrypt is intercepting there I/O & returning a decrypted value of the zeroes on disk, I should be able to disconnect the SSD & plug it into another PC (not running VeraCrypt) as a secondary drive and run HxD. HxD should then correctly display the zeroed sectors.
I am not familiar with drive optimization in Win7. Are you referring to running WinSAT? If so, yes, I have a script I run when setting up a new PC, which makes all the WinSAT SSD optimizations.
Thanks for your reply & all the info. I have, like Break Stuff above, reluctantly switched to BitLocker, but I will test VeraCrypt again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"VeraCrypt does not block the trim operation on partitions that are within the key scope of system encryption (unless a hidden operating system is running) and under Linux on all volumes that use the Linux native kernel cryptographic services"
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you are using VeraCrypt with a SSD, be careful about the problems of using it on drives that use Wear-Leveling, like SSDs:
This is from the documentation - https://veracrypt.eu/en/Wear-Leveling.html:
"If you need plausible deniability, you must not use VeraCrypt to encrypt any part of (or create encrypted containers on) a device (or file system) that utilizes a wear-leveling mechanism."
Last edit: asewafea 2023-03-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From the VeraCrypt documentation link: "VeraCrypt does not block the trim operation on partitions that are within the key scope of system encryption"
From this statement, it sounds like both FDE and System Partition Encryption would allow TRIM passthrough.
I did the following steps, but could not get TRIM to work on an encrypted system partition.
1) Created a 200GB partition on a new 256GB SSD.
2) Installed Win 7 Pro x64 (legacy bios mode) on the 200GB partition.
3) Booted into Windows and verified TRIM was activated via "fsutil behavior query DisableDeleteNotify".
4) Ran TrimCheck and verified TRIM was working.
5) Used HxD Hex Editor to view raw disk sectors to verify unused sectors were still zeroed.
6) Installed VeraCrypt and encrypted the 200GB System Partition only (not entire drive). Encryption was successful.
7) Rebooted and verified with HxD Hex Editor that all sectors, including previous zeroed sectors, now contained data.
8) Verified TRIM was still activated via "fsutil behavior query DisableDeleteNotify".
9) Ran TrimCheck again, but now TRIM is not working.
10) Tried to do a manual TRIM with SSDTool, but didn't work.
11) Tried to do a manual TRIM with ForceTrim, but didn't work.
Does anyone have any advice or experience with TRIM working on an encrypted system partition?
Just wanted to second the post above. I had pretty much the exact same experience just now. Have you found a fix yet? I was wondering if maybe the drive needs to be set to AHCI in the BIOS before the Windows install, but I don't even have that option in the BIOS, even though this is a new laptop. On the other hand, if AHCI was the issue, then why did TrimCheck work before the encryption? I also tried the following VeraCrypt feature, to no avail: "Enable extended disk control codes support".
This is pretty frustrating, as it leads me to believe that VeraCrypt is a no-go for SSDs afterall. Notice the careful wording saying it "does not block" trim operation, instead of actually positively stating that it will indeed pass-through the trim operations. I now turn to my frenemy, Bitlocker. :(
I have run sevral tests using system encryption with SSD under Windows 10 and I didn't see any issue with TRIM. TRIM commands are received by VeraCrypt driver and they are transfered correctly to the SSD. So TRIM support for system encryption is still OK and the documentation is valid.
I believe you were mislead by the fact that both tools TrimCheck and HxD return data that are different from what is stored on disk because VeraCrypt intercept there I/O and the data returned is the result of decryption of what is stored on the disk.
For TrimCheck, it will conclude that TRIM status is INDETERMINATE because the data it reads is not zeros but actually the data returned is the result of the decryption of zeros which are actually stored on the disk! To convince yourself, run TrimCheck 4 times in a row so that he uses the same disk position for its tests and you will notice that the data he reads is always the same although it is writing random data each time.
For HxD, the same thing happens: the data it reads are the result of the decryption done transparently by VeraCrypt and not what is really stored on the physical drive. That's why HxD does not display zeroes and it displays data that is the result of the decryption of zeros!
I didn't run the tools SSDTool and ForceTrim but clearly they are affected the same way as TrimCheck since they can not read the zeros stored on the SSD and they get decryption output of VeraCrypt instead.
One important thing to note: to enable TRIM support in Windows, it is not enough that the usual fsutil command outputs 0, you also need to active drive optimization in Windows. In some cases, Windows doesn't enable system drive optimization automatically and it must be enabled manually (for example https://www.tenforums.com/windows-updates-activation/61792-cannot-trim-ssds-after-windows-10-anniversary-update.html)
Hi Mounir IDRASSI,
So, if VeraCrypt is intercepting there I/O & returning a decrypted value of the zeroes on disk, I should be able to disconnect the SSD & plug it into another PC (not running VeraCrypt) as a secondary drive and run HxD. HxD should then correctly display the zeroed sectors.
I am not familiar with drive optimization in Win7. Are you referring to running WinSAT? If so, yes, I have a script I run when setting up a new PC, which makes all the WinSAT SSD optimizations.
Thanks for your reply & all the info. I have, like Break Stuff above, reluctantly switched to BitLocker, but I will test VeraCrypt again.
The VeraCrypt documentation - https://veracrypt.eu/en/Trim%20Operation.html
mentions the cases where it will disable the TRIM operation:
"VeraCrypt does not block the trim operation on partitions that are within the key scope of system encryption (unless a hidden operating system is running) and under Linux on all volumes that use the Linux native kernel cryptographic services"
If you are using VeraCrypt with a SSD, be careful about the problems of using it on drives that use Wear-Leveling, like SSDs:
This is from the documentation - https://veracrypt.eu/en/Wear-Leveling.html:
"If you need plausible deniability, you must not use VeraCrypt to encrypt any part of (or create encrypted containers on) a device (or file system) that utilizes a wear-leveling mechanism."
Last edit: asewafea 2023-03-29