Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.hardware > #2523
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.os.linux.hardware |
| Subject | Re: SSD drive reliability. |
| Date | 2014-08-13 15:52 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <lsfqim$nqe$1@dont-email.me> (permalink) |
| References | (9 earlier) <op.xhlxnuz0a3w0dxdave@hodgins.homeip.net> <lnrhaj$giu$1@dont-email.me> <slrnlumb5u.kqo.fredrik@biggles.jonson.org> <lsfh13$mr1$1@dont-email.me> <wwvtx5gfvmu.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf87AxnpFoA.invalid> |
On 13/08/14 13:59, Richard Kettlewell wrote: > David Brown <david.brown@hesbynett.no> writes: >> The other fix (which may be in the Sata 3.1 specs - I haven't bought >> them to look) would be to specify that a trimmed block reads as all >> zeros. At the moment, some drives return zeros, some return the old >> data, some return whatever happened to be in the drive's cache, and >> some might return data that is logically in another part of the disk. >> This all has two problems - one is data security, and the other is >> that it is a wasted opportunity for disk formatting and for raid. If >> returning zeros for read of a trimmed block were mandated, >> initialising and synchronising a new raid array would be done with a >> couple of trim commands. > > I don’t think TRIM is a good choice of command to overload with secure > erase functionality. > > The main reason is that does not actually erase anything. Simply > requiring it to return 0 for discarded logical blocks would not > guarantee that your data could not be recovered by someone in possession > of the device. > > Additionally, if your data is confidential after being erased, it must > be confidential before erasure too. As such you are better off with a > mechanism that protects it at all times, e.g. encryption. > There is a difference between not being a security function, and being a security hole. I don't think TRIM should be considered a security feature or an alternative to secure erase - for exactly the same reasons as you. But I also don't think the SSD should be allowed to return random data, old data, or data that belongs to other parts of the disk when you read from a TRIM'ed block. Returning all zeros is the most helpful and consistent way to treat TRIM'ed blocks - with the benefit of giving the disk a very cheap way to write large blocks of zeros (without claiming to do so in a highly secure manner).
Back to comp.os.linux.hardware | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
SSD drive reliability. wexfordpress <john@wexfordpress.com> - 2014-06-09 15:49 -0700
Re: SSD drive reliability. Bob Tennent <BobT@cs.queensu.ca> - 2014-06-09 23:13 +0000
Re: SSD drive reliability. Måns Rullgård <mans@mansr.com> - 2014-06-10 00:57 +0100
Re: SSD drive reliability. Bob Tennent <BobT@cs.queensu.ca> - 2014-06-10 00:54 +0000
Re: SSD drive reliability. Måns Rullgård <mans@mansr.com> - 2014-06-10 02:01 +0100
Re: SSD drive reliability. Bob Tennent <BobT@cs.queensu.ca> - 2014-06-10 01:15 +0000
Re: SSD drive reliability. "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2014-06-14 07:50 +0000
Re: SSD drive reliability. Poutnik <poutnik@privacy.net> - 2014-06-14 10:19 +0200
Re: SSD drive reliability. "Trevor Hemsley" <Trevor.Hemsley@mytrousers.ntlworld.com> - 2014-06-14 21:10 -0500
Re: SSD drive reliability. "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2014-06-15 08:48 +0000
Re: SSD drive reliability. David Brown <david.brown@hesbynett.no> - 2014-06-16 10:41 +0200
Re: SSD drive reliability. "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2014-06-17 10:24 +0000
Re: SSD drive reliability. Måns Rullgård <mans@mansr.com> - 2014-06-17 12:24 +0100
Re: SSD drive reliability. Richard Kettlewell <rjk@greenend.org.uk> - 2014-06-17 12:44 +0100
Re: SSD drive reliability. David Brown <david.brown@hesbynett.no> - 2014-06-17 14:43 +0200
Re: SSD drive reliability. "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2014-06-17 12:34 -0400
Re: SSD drive reliability. David Brown <david.brown@hesbynett.no> - 2014-06-18 10:06 +0200
Re: SSD drive reliability. "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2014-06-19 16:29 -0400
Re: SSD drive reliability. Fredrik Jonson <fredrik@jonson.org> - 2014-08-13 09:15 +0000
Re: SSD drive reliability. David Brown <david.brown@hesbynett.no> - 2014-08-13 13:09 +0200
Re: SSD drive reliability. Richard Kettlewell <rjk@greenend.org.uk> - 2014-08-13 12:59 +0100
Re: SSD drive reliability. David Brown <david.brown@hesbynett.no> - 2014-08-13 15:52 +0200
Re: SSD drive reliability. JEDIDIAH <jedi@nomad.mishnet> - 2014-06-09 19:45 -0500
Re: SSD drive reliability. David Brown <david.brown@hesbynett.no> - 2014-06-10 08:51 +0200
Re: SSD drive reliability. "Vince Coen" <VBCoen@gmail.com> - 2014-06-10 11:49 +0100
csiph-web