geli+trim support

[Julian Elischer]

On 7/5/14, 9:11 AM, Jesse Gooch wrote:
> Hi,
>
> On 04/07/14 01:19 AM, Poul-Henning Kamp wrote:
>> In message <53B6427D.1010403 at gooch.io>, Jesse Gooch writes:
>>
>>> IIRC, TRIM is bad for encryption anyway. You want everything to be
>>> random noise, even the empty sectors. TRIM defeats this.
>> The problem is that there is nothing you can do.
>>
>> If you overwrite, your old sector is still unchanged somewhere in flash.
>>
>> If you TRIM, your old sector is still unchanged somewhere in flash, but
>> if you're lucky for slightly less time.
> Perhaps I misunderstand TRIM, isn't the point of TRIM that it zeroes out
> the sector ahead of time so it doesn't have to re-do it again when it
> stores more data in that sector later?

hmm, no. 'trim' tells the drive that the sector in question is
to be trimmed from the list of sectors with any valid information.
On a "flash" drive this tells teh drive that it is free to reassign it 
to some other
use shoudl it need to. This is differnet from "writing zeros to it" 
which would
be a valid sector, full of data (zeros).


>
>> Doing both just means that you have both the original and the overwritten
>> content lingering in flash.
>>
>> GBDEs scheme with per sector PRNG keys is marginally better than
>> GELIs, in that the chances that both the sector and its key survives
>> is only 3/4 of the chance that the sector survives.
>>
>> Without access to and control over the Flash Adaptation Layer,
>> encrypting SSDs so they are safe against hardware access is impossible.
>>
>> For the paranoid:  ... and a hostile FTL can make it much harder.
>>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>