Can a work around be to fill the disk up with unimportant files and then encrypt?
To a certain extent. That will work if no blocks have been blocked (marked bad by the controller). If not, which could be quite likely on an older drive, the question then becomes if potentially sensitive data could persist there regardless of user action. Again, this becomes an issue of how paranoid you have to be.
Writing random data to a huge device-filling file and then erasing it is equivalent to a secure-delete operation.
All of the user-accessible disk blocks will either be random data or zeros (depending on if TRIM is used), and your old data will be garbage in the flash chips, until garbage collection runs.
Encryption at this point will be as I wrote, above. The data will be inaccessible to anyone who isnât able to bypass the SSD controller.
How would you do that ? thank you
I read somewhere that if you fill an SSD drive more than 3/4 full (or some similar number) it will cause slowdowns and even if you delete the files, the slowdown stays. Is that true?
1 Like
Thatâs related to garbage collection. If you write to 100% of the disk, then delete 1% of it, and the you want to add 1%, GC first needs to run to ensure that the 1% becomes available again. If GC hasnât already done so (if the SSD is left idling for long enough, GC should always run), that needs to happen right then and there, and that can introduce a penalty. By ensuring ~20% of the SSD remains unused (and I readily admit that is a conservative estimate these days), you increase the chances that you have blocks readily available any time you want to write. Note that advice to not partition these 20% is nonsense (perhaps related to provisioning missing on early SSDs, see below). Itâs perfectly fine to partition 100%, just donât occupy every last bit with data.
Itâs worth pointing out also that this shouldnât be mistaken with leaving space to make up for bad blocks that get mapped out by the controller. SSDs already provide that and any decent model you buy today will come with ample such extra space included. Itâs called provisioning. On higher-end SSDs intended for example for servers (where you anticipate very many write cycles), that can amount to as much 50% from what Iâve been told.
And finally, if you have TLC flash from certain manufacturers that doesnât come with large DRAM cache, it could be youâd want to leave free space because of dynamic provisioning. If you leave more of the SSD free, certain drives will switch TLC cells to function as SLC which can increase performance significantly. If you have such a drive and you let it fill up, you are essentially forcing it to run entirely as true TLC with the associated penalty over âpseudo-SLCâ.
1 Like
After reading your post, I read about TRIM because I found interesting the fact that formatting with TRIM insures a secure erase.
I checked and all Samsung SSD drives are trim enabled. However, it seems that Mac recognizes the trim only if the external SSD is connected with a Thunderbolt cable.
This surprised me and indeed when I plug my Samsung T7 portable which works perfectly, the system report does not report TRIM supported when connected via either USB A or USB C. I donât have a thunderbolt cable to test that type of connection.
I am sure that you highly performant EVO is TRIM âcapableâ but is it enabled in your mac ?
I would make a big file in Photoshop PSB format. If you do not have Photoshop you can download a trial.
1 Like
Te easiest way to create a file that fills all your free space is to use the command line:
cat </dev/zero >bigtempfile
Once you run out of disk space, the command will fail with an error message. You can then immediately delete bigtempfile. Be aware that, if youâre doing this on your boot drive, your system will become unstable as the system disk approaches full.
Edit: the above command will create bigtempfile in the current directory (âfolderâ), which will default to one on the boot drive. If youâre wanting to do this on something other than the system drive, you need to specify the localtion of bigtemptfile:
cat </dev/zero >/Volumes/[driveToBeErased]/bigtempfile
5 Likes
thank you. Perhaps a video ?
thank you very much.
@ron
Because I am bungle prone, How could I insure that itâs the external SSD being filled up ?
@ron @paal
Isnât secure delete exactly that: filling in the disk with 0 and 1 ?
Secure delete overwrites most of the disk, yes. I was focusing on the question of âhow do I create a file that uses up all the free space?â
As others have said, the correct answer is to always use whole-disk encryption from the beginning. Sometimes, the âcreate a big file of zerosâ technique is useful when you have an unencrypted disk, donât necessarily want to erase all the files on it, but want to make reasonably sure that information from previously deleted files isnât trivially recoverable. I realize that isnât the context in which the question was asked.
The problem this whole thread seems to be struggling with is the fact that modern systems, with smarts in the disk (SSD) controller and complex features in the file system, make it difficult to make absolutely sure that your storage medium is actually 100% erased.
2 Likes
Just to be clear: I was trying to understand. I did not mean to question your approach,
If I understand correctly
- itâs not 100 % as you say
- at the same time, I gather from other posts that recovering the data would be quite an endeavour. It would take a determined hacker, not just a service repairman at my local apple service store.
thanks again
Thatâs not so much about the cable but about macOS driver support. So just attaching your T7 to a TB port with a TB cable wonât change any of that.
Youâd need an actual TB drive, i.e. flash memory interfaced to your Mac over TB (such as an X5). There are TB-NVMe cases and they work fine, but theyâre usually much more expensive than USB-attached SSDs which commonly bridge either SATA (slower, cheaper) or NVMe (faster, more expensive, can require cooling to ensure real benefit) to USB 3.x. Of course they also offer much better performance, especially when they are cooled.
The bottom line here is that macOS supports TRIM on external drives when they interface through PCIe, but not USB*. Macs have IMHO always had somewhat mediocre USB drive support. The keyword here though is PCIe and thatâs why TB-attached drives get it (TB is based on PCIe) and USB-attached donât.
*) The exception being drives with bridge chips that support UASP. Those drives should allow for TRIM, well technically UNMAP (in SCSI terminology, TRIM is what it was called as an ATA command) when attached to a Mac over USB. Iâm not sure if the T7 actually supports this. Itâs been a long time since I looked into this, but IIRC you should be able to check if the drive youâve attached is making use of UASP by running a
ioreg | grep IOUSBand checking on the line for your drive it you see something like
class IOUSBMassStorageUASDriver, id 0x100008489, registered, matched, active, busy 0 (100 ms), retain 9The active part is what you want to see.
My memory here is a bit foggy so Iâm hoping somebody will double-check me on that.
BTW, those 970 EVO I was playing around with are NVMe-interfaced flash that we hook up using a TB3 enclosure (OWC Envoy Express is an inexpensive example, but also no active coolingâthere are fancier alternatives) so theyâll always show TRIM support since the Mac talks to them through PCIe, just as it does with its internal flash.
2 Likes
This is definitely correct.
Itâs not like anybody attaching that old drive and accessing it through its built-in controller would be able to read out your old data. Accessing such leftover data would require bypassing the controller (so for example T2 or M1/2 Macs make that impossible right away thanks to their built-in hardware-level flash encryption regardless of usersâ specific FV2 choices) and reading out flash cells directly.
To be clear: that can be done. Forensic analysis attempts to do exactly that and there are ample cases where it has shown to have been successful. However, it is also correct to point out that this is very involved, requires lots of time, expertise and hence money.
If you are a Russian dissident who is harboring information that could topple Putin, you would absolutely be at risk. Or if you are a multi-billion $ company who has its trade secrets on an old company notebook one of your dunce employees just forgot at the gate. But any regular Joe like myself is most likely not at great risk for that attack vectorâitâs just too much effort for too little gain. There are much cheaper methods to scam me, rip me off, or access my staffâs PII from one of my systems (eg. social engineering [I like to believe I wonât fall for that] or much simpler, just pointing a gun at my head). XKCD as usual had a good summary of that.
4 Likes
Very wise precaution! So the cat </dev/zero part on its own is harmless. You want to be sure the output has the right target. Using the template @ron gave you above, you have by now likely a best guess of that target. Letâs say youâre pretty sure itâs /Volumes/TroublesomeSSD/bigtempfile. Try this command first, just to validate the target:
echo "TidBITS Talk is wonderful!" > /Volumes/TroublesomeSSD/bigtempfile
That will complete in an instant. Then, if you see the file bigtempfile on your SSD, youâre in business. If not, youâve only written a 26 byte file to the wrong target.
2 Likes
thanks VERY much for a brilliant explanation. The cartoon says it all !
excellent approach. Thanks very much.
Your comments are so interesting ! I am writing a summary.
If you have the patience - I am completely new at this.
Below is a typical SSD I use for backup
- do I have to repeat the terminal command for all disks , ie disk7S1 to S4 (column on the right) or the physical disk6s2 ?
- itâs not clear for me what I should write in place of volume
- could you give one example of a terminal command based on this actual drive ? I am trying to figure out what to write in the place of
- in the command, do I include / / and ?
cat </dev/zero >/Volumes/[driveToBeErased]/bigtempfile
thanks very much
