All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Nichols <rnicholsNOSPAM@comcast.net>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Prepare SSD for encrypted linux install
Date: Wed, 8 Nov 2017 18:34:38 -0600	[thread overview]
Message-ID: <ou07qm$61b$1@blaine.gmane.org> (raw)
In-Reply-To: <20171108183632.86d664bf5f369380a2d4fb88@bluenox07.de>

On 11/08/2017 11:36 AM, Merlin Büge wrote:
> Hello all,
> 
> 
> I want to use an SSD (Samsung 850 PRO 512GB) for a fully encrypted Linux
> system. I've read the cryptsetup FAQ and various posts in the
> internet and I'm familiar with the common problems/pitfalls regarding
> dm-crypt on SSDs.
> 
> To avoid information leakage about the storage device's usage patterns,
> it is generally recommended to fill the entire device with random data
> before setting up encryption. It is also recommended to issue an 'ATA
> secure erase' to SSDs before using it to avoid performance issues.
> 
> But doing these two things, either my (1) random data gets 'deleted' via
> the (2) 'ATA secure erase' (the SSD will report all zeros), or I end up
> with degraded performance when (1) issuing 'ATA secure erase' before
> (2) putting random data on it.
> 
> I thought of TRIMing the SSD via 'blkdiscard' instead of using
> 'ATA secure erase' after putting random data on it (twice, see [0]),
> but that should make no difference, since the SSD will most probably
> report all zeros for TRIMed sectors. Either way, the flash chips will
> contain all random data ...

No, they won't. They will all be cleared. The whole point of TRIM or blkdiscard is to allow the controller to clear the blocks of flash cells so that they will be immediately available for writing when needed. Writing random data to the flash cells and then immediately clearing them is fairly pointless. All it does is mask any residue a cleared cell might have of the last data it contained. People who need that level of security don't ask about it here.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

  parent reply	other threads:[~2017-11-09  0:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-08 17:36 [dm-crypt] Prepare SSD for encrypted linux install Merlin Büge
2017-11-08 18:45 ` Heinz Diehl
2017-11-08 21:45 ` David Christensen
2017-11-09  0:34 ` Robert Nichols [this message]
2017-11-09 10:55   ` Arno Wagner
2017-11-09 11:05   ` Merlin Büge
2017-11-09 12:20     ` Arno Wagner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='ou07qm$61b$1@blaine.gmane.org' \
    --to=rnicholsnospam@comcast.net \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.