geli+trim support

Stefan Esser se at freebsd.org
Fri Jul 4 10:29:45 UTC 2014


Am 04.07.2014 07:58, schrieb Jesse Gooch:
> IIRC, TRIM is bad for encryption anyway. You want everything to be
> random noise, even the empty sectors. TRIM defeats this.

Does it? The NAND blocks that are trimmed are put back on the internal
free list of the device, and may still be accessible (at least with
diagnostic commands). But their contents should have been encrypted
and thus "look" like random noise. This is a problem of all flash
devices, that you can only access through an flash adaptation layer.
Even trying to overwrite the old data "in place" is likely to preserve
the old blocks and to write to new blocks (due to wear-leveling).

TRIM lets the device know, that the block should be considered empty
(and reads will return dummy data), while "overwriting" with random
will make a read return that data. You should not be able to access
the old contents with regular read commands, in either case. And with
diagnostic commands, you'll probably still be able to read the old
(encrypted) content. But TRIM may lead to blocks being erased and
reused earlier, than without TRIM.

So, I do not think that TRIM is weakening file system encryption ...

Regards, STefan


More information about the freebsd-hackers mailing list