Re: simple ideas addressing ssd TRIM security concern

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 16, 2012 at 01:28:25AM +0100, alban bernard wrote:
> --- On Mon, 4/16/12, Sven Eschenberg <sven@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > An erase block is a continuous block of sectors. As long as
> > not all FS
> > blocks covering this erase block were trimmed, the advantage
> > of trimming
> > is anihilated (for obvious reasons). As an example, assume a
> > 64k erase
> > page size and 4k FS-blocks. Now erase a big file (i.e. 1GB),
> > while only
> > trimming 1% of the covered space randomly. The probability
> > that you'd TRIM
> > multiple sets of 16 continuous FS blocks (if we assume
> > proper alignment)
> > when only trimming 1% of the 1GB file is next to zero. If
> > the FS blocksize
> > is smaller and the erase page size bigger, it's even worse.
> 
> To me, due to the "virtual" LBA table allocation handled internally by the
> ssd controller and in the case TRIM is allowed and fully used accross the
> entire device, the big file of 1GB is already erase-block fragmented. 
> That is the purpose of the garbage collector: aggregating valid pages to
> isolate discarded pages inside future "erasable" blocks.
> 
> In my case, the probability is maybe next to zero (not sure about that),
> right after sending the TRIM commands on the 1% percent of the big file. 

You fogte that any malicious use of that feature could be aware
of the details and compensate. Then the probability becomes 100%.

> But after a certain amount of time, the garbage collector will un-puzzle
> all the mess and help the controller to erase trimmed blocks (those 1%
> aggregated with another erasable pages).
> 
> > As Arno already said, all you can do is weigh out leakage
> > versus performance.
> 
> Weighing out really is the most difficult part when you have no tangible
> data: how much is it difficult to break a TRIMed and crypted device?

It is not difficult. It is impossible. Therefore a sane secure
design tries not to do it but forbids TRIM in the first place.

If security requirements are lower, the design can allow the user
to enable it, but even having the possibility in there is a risk.

You are of course free to compromise the security of your own system
as far as you like. But default mechanisms must be held to a higher
standard. 

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux