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
