Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.os.linux.hardware > #2523

Re: SSD drive reliability.

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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