Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Anyone know what can happen if we use the unpartitioned space of an SSD hard drive to hide some data, what would happen?

I have read that there are some SSD firmware using these blocks for recycling (TRIM). If so hidden data would be lost.

Could someone explain what would happen with the hidden data?


share|improve this question
Why go that far? Isn't steganography within simple files enough for you? – YoMismo Feb 4 '14 at 9:26

Nothing would happen. The SSD does not know nor care about your partitions. If you write data to any location, the data will stay at this location. If the SSD decides to shuffle blocks internally, it will copy the data to the new block, so it stays available at the same logical position.

If you do this and then the key is gone at some point, it was either overwritten, or the area was explicitely trimmed. This can happen when you repartition your disk in any way or if your partitioning software tries to be smart and trims any partition you delete and any free space between partitions. For example LVM does this when you set issue_discards = 1 in your lvm.conf.

It's not something the SSD decides on its own, though.

You still should not hide your encryption key in such a way. If it's obvious from your Initramfs scripts that the key is hidden in such a way, even if the exact location is not known, it could be bruteforced.

share|improve this answer

Your question is based on the assumption that the unpartitioned space is used for wear-leveling, which is not correct. Most wear-leveling algorithm uses the free space, not the unpartitioned space. Leaving unpartitioned space on your drive is therefore a waste. I can't find any definitive say, but several search results agree on this.

Given that the myth is busted, I'm going to say that it's safe to store data in the unpartitioned space if you want to do it that way. The drive won't destroy your data as part of normal usage.

The remaining question is whether it's wise to hide your data there, which you didn't ask... I agree with @frostschutz. Hiding your data in the unpartitioned space won't make it any harder for an attacker. It just makes things more troublesome (and confusing, if you look at the setup a year from now when you start to forget the details) for you. I would just keep the encryption key in a normal file, encrypted with a strong password and keep the password in my head.

share|improve this answer
This question is for embedded Linux machine. There is no possibility of introducing any password or connect to a server to get the password. – Alfredo Pons Menargues Feb 4 '14 at 10:16
Does the embedded machine have the performance necessary for encryption? If not, using an SSD with built in encryption feature may be a good option. It's not what I'd choose on a desktop but embedded has usually different priorities, and your mechanism won't be very secure either way. – frostschutz Feb 4 '14 at 10:38
when your disk controller (like most raid controllers) or OS doesn't support TRIM/UNMAP, then leaving space unallocated (and using the HPA or unpartitioned data are the most obvious solutions) is the only option. If you don't, then even if you have 20% free space on your filesystem, you've got no guarantee that your filesystem will have written all the sectors on disk leaving no space for the SSD firmware to have a pool of blank blocks. Note that it is for write performance improvement, not that much for wear levelling. – Stéphane Chazelas Feb 4 '14 at 10:41

Depends what you mean by unpartitioned.

If you mean hidden areas like the Host Protected Area as set with hdparm -Np, then maybe some SSD firmware would assume that area is free for use as a pool of erased blocks.

If not, then no. The SSDs are not going to read the content of the drive to figure out how the system intends to use it. If the data has been written by the system and not trimmed thereafter (still by the system), then the SSD controller won't take upon itself to erase it.

Unpartitioned areas may be use for over provisioning only if it's been trimmed (or never written since the SSD was manufactured).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.