linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 92271] Provide a way to really delete files, please
Date: Sun, 01 Feb 2015 01:51:46 +0000	[thread overview]
Message-ID: <bug-92271-13602-HA2vvcLnJ7@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-92271-13602@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=92271

--- Comment #13 from Theodore Tso <tytso@mit.edu> ---
I don't like making promises that I can't be 100% sure I can keep.   For
example, it's possible to create storage devices that simulate a read/write
disk but which is backed on top of a write-only drive, where the copy-on-write
is done at the storage device level.   You can set up such a beast using ceph,
for example.

The only real solution if you want to be able to give away a phone and make
sure that the next owner can't recover anything at all is to use encryption.  
So for example, if you buy a Nexus 6, it comes with encryption enabled by
default, and if you do a factory reset, one of the things that happens is that
the key which can be derived from your pin/password (the downside is you have
to type in your pin after every single reboot/power cycle), and that will
guarantee that your data is secure.  In fact, all of GCE's VM storage options
provide encryption as a non-optional feature.  See
https://cloud.google.com/compute/docs/disks

This is how Google Compute Engine guarantees security for its local SSD product
offering --- each SSD attached to each VM gets its own encryption key, and when
the VM is destroyed, the encryption key is flushed, and that way you don't have
to feed the SSD to a shredder (which is the *only* other way to 100% guarantee
that all of the data is deleted).  In the commercial world (never mind the
military world), you really care about your reputation, which means that you
must make sure that data can never leak, which is why you don't trust the FTL,
and you don't trust vendors claims around "trim" or "secure trim".   You use
crypto.

So if you want to use crypto, what to do?   You can either use dm-crypt or
ecryptfs, which is what Android and Chrome are currently using, or we're
currently working on an ext4 encryption feature which will give you per-file
control over which keys get used for which files.   This feature is still very
much in development, so if it breaks, you can keep both pieces, but this is why
I'm not terribly interested in wasting time trying to wire up secure discard.  
If someone else wants to send me patches, I'll look at them, but personally I
don't think it's a good use of my time.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

  parent reply	other threads:[~2015-02-01  1:51 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-29 11:47 [Bug 92271] New: Provide a way to really delete files, please bugzilla-daemon
2015-01-29 19:13 ` [Bug 92271] " bugzilla-daemon
2015-01-29 19:30 ` bugzilla-daemon
2015-01-29 19:49 ` bugzilla-daemon
2015-01-29 20:59 ` bugzilla-daemon
2015-01-29 21:01 ` bugzilla-daemon
2015-01-29 21:20 ` bugzilla-daemon
2015-01-29 21:55 ` bugzilla-daemon
2015-01-29 22:02 ` bugzilla-daemon
2015-01-29 22:11 ` bugzilla-daemon
2015-01-31 17:21 ` bugzilla-daemon
2015-01-31 18:36 ` bugzilla-daemon
2015-01-31 20:56 ` bugzilla-daemon
2015-02-01  1:51 ` bugzilla-daemon [this message]
2015-02-01  1:58 ` bugzilla-daemon
2015-02-01 10:14 ` bugzilla-daemon
2015-02-01 10:35 ` bugzilla-daemon
2015-02-01 11:04 ` bugzilla-daemon
2015-02-01 16:33 ` bugzilla-daemon
2015-02-01 17:18 ` bugzilla-daemon
2015-02-02  8:32 ` bugzilla-daemon
2015-02-02 11:13 ` bugzilla-daemon
2015-02-02 17:12 ` bugzilla-daemon
2015-02-03 17:29 ` bugzilla-daemon
2015-02-03 17:44 ` bugzilla-daemon
2015-02-03 17:47 ` bugzilla-daemon
2015-02-03 18:20 ` bugzilla-daemon

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=bug-92271-13602-HA2vvcLnJ7@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    /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).