linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Philipp <philipp.guendisch@fau.de>
To: Damien Le Moal <damien.lemoal@wdc.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-block@vger.kernel.org, axboe@kernel.dk,
	viro@zeniv.linux.org.uk, bart.vanassche@sandisk.com,
	martin.petersen@oracle.com, hare@suse.de, osandov@fb.com,
	dan.j.williams@intel.com, ming.lei@redhat.com,
	linux-kernel@i4.cs.fau.de, Mate Horvath <horvatmate@gmail.com>
Subject: Re: [PATCH] Support for secure erase functionality
Date: Thu, 14 Sep 2017 14:51:52 +0200	[thread overview]
Message-ID: <B5C3A846-D993-4356-8F89-1CEE253D54F7@fau.de> (raw)
In-Reply-To: <2b2d3855-00e9-77d0-7ee4-050c210b718e@wdc.com>

Dear Damien,

Thank you for your feedback. 

> On 14. Sep 2017, at 10:46, Damien Le Moal <damien.lemoal@wdc.com> wrote:

[…]

> Writing once to a sector stored on spinning rust will *not* fully erase
> the previous data. Part of the signal used for storing that data will
> remain on the track (because the disk head is never perfectly aligned on
> the track). With some signal processing work, the old data can be retrieved.
> 
> You will need a *lot* of normal writes to make sure nothing remains of
> the old data signal. Granted, even a single write will make it hard to
> get to the old data, but it is possible nevertheless. Hence the standard
> defined SANITIZE with cryptographic erase option to ensure that the old
> data is really dead.


We constructed our patch based on a paper called 
“Overwriting Hard Drive Data: The Great Wiping Controversy” which stated that a single overwrite
of the data is sufficient.
Nevertheless this should not be a solution to replace encryption but to improve data security when
better techniques are not viable (e.g. travelling between countries while importing or exporting
encrypted data may be prohibited without a license).

> I think that a similar problem also exist for SSDs, and it is even worse
> there since writing twice to the same logical sector does not even go to
> the same physical sector. The old data is not even overwritten.

We know about the problems regarding the data placement on SSDs, but there is very little we can
do with code against the hardware controller of specific devices.
On SSDs, you would probably want to use full disk encryption, because it should be no problem,
when encrypted blocks are left on the drive.

However in cases where encryption is too slow or not possible, this could improve data confidentiality.

Best regards,
Philipp

  reply	other threads:[~2017-09-14 12:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-13 15:37 [PATCH] Support for secure erase functionality Philipp Guendisch
2017-09-14  8:17 ` Johannes Thumshirn
2017-09-22  9:54   ` Máté Horváth
2017-09-14  8:46 ` Damien Le Moal
2017-09-14 12:51   ` Philipp [this message]
2017-09-15  2:46     ` Damien Le Moal
2017-11-15 21:12   ` Pavel Machek

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=B5C3A846-D993-4356-8F89-1CEE253D54F7@fau.de \
    --to=philipp.guendisch@fau.de \
    --cc=axboe@kernel.dk \
    --cc=bart.vanassche@sandisk.com \
    --cc=damien.lemoal@wdc.com \
    --cc=dan.j.williams@intel.com \
    --cc=hare@suse.de \
    --cc=horvatmate@gmail.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@i4.cs.fau.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=ming.lei@redhat.com \
    --cc=osandov@fb.com \
    --cc=viro@zeniv.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).