Date: Fri, 04 Jul 2014 12:29:23 +0200 From: Stefan Esser <se@freebsd.org> To: "hack >> \"freebsd-hackers@freebsd.org\"" <hackers@freebsd.org> Subject: Re: geli+trim support Message-ID: <53B68203.2030704@freebsd.org> In-Reply-To: <53B6427D.1010403@gooch.io> References: <alpine.BSF.2.00.1407020036280.4507@wojtek.tensor.gdynia.pl> <7E2718485A3E405D89E5EAB331E9ED70@multiplay.co.uk> <53B6427D.1010403@gooch.io>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53B68203.2030704>