From: Theodore Ts'o <tytso@mit.edu>
To: "Lukáš Czerner" <lczerner@redhat.com>
Cc: JP Abgrall <jpa@google.com>, Dave Chinner <david@fromorbit.com>,
Eric Sandeen <sandeen@redhat.com>,
linux-ext4@vger.kernel.org, Geremy Condra <gcondra@google.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] ext4: Add support for SFITRIM, an ioctl for secure FITRIM.
Date: Wed, 18 Jun 2014 18:06:01 -0400 [thread overview]
Message-ID: <20140618220601.GA5114@thunk.org> (raw)
In-Reply-To: <alpine.LFD.2.00.1406181125440.3406@localhost.localdomain>
On Wed, Jun 18, 2014 at 11:33:47AM +0200, Lukáš Czerner wrote:
> Except when it does not. Looking at the mmc driver I can see that we
> have already some devices where secure trim is broken.
>
> /*
> * On these Samsung MoviNAND parts, performing secure erase or
> * secure trim can result in unrecoverable corruption due to a
> * firmware bug.
> */
The bug IMHO is that the eMMC driver is falling back to discard,
instead of returning EOPNOTSUPP. The question of whether we should
fall back to discard or not should be made at a level much higher up
than the MMC device driver....
> And I have no illusion that those are the only ones that does not
> work. This hardware can not be trusted and this must not be
> advertised as a security feature.
There's always crappy hardware out there. If that's true, should then
not call ATA Secure Erase by that term because somewhere out there,
there will be an incompetently implemented SSD that doesn't do the
right thing with ATA Secure Erase? I just don't think that's
particularly useful. If the command is called "secure erase" or
"secure discard" in the specification, then that's what we should use,
just to avoid confusion if nothing else.
Now, if the spec explicitly disclaims correct behavior, in the case of
discard and discard zeros data, that's a different matter. But I
don't think that is what's going on here. The MMC specification makes
certain guarantees; there is no "the drive is allowed to disregard the
discard command if it's too busy to attend to it mealy-mouthed
language", as there is in the ATA discard specification.
The fact that there happens to be buggy hardware out there, is just
the natural state of affairs. But that's what black lists are for.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-06-18 22:06 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1402625647-31439-1-git-send-email-jpa@google.com>
2014-06-13 2:36 ` [PATCH] ext4: Add support for SFITRIM, an ioctl for secure FITRIM Eric Sandeen
2014-06-13 3:02 ` JP Abgrall
2014-06-13 3:12 ` Eric Sandeen
2014-06-13 3:19 ` JP Abgrall
2014-06-13 3:24 ` Eric Sandeen
2014-06-13 4:37 ` JP Abgrall
2014-06-13 3:15 ` Dave Chinner
2014-06-13 3:30 ` Dave Chinner
2014-06-13 4:37 ` JP Abgrall
2014-06-13 5:07 ` Dave Chinner
2014-06-13 14:20 ` Theodore Ts'o
2014-06-13 14:31 ` Theodore Ts'o
2014-06-13 19:44 ` JP Abgrall
2014-06-13 19:57 ` Eric Sandeen
2014-06-13 20:12 ` JP Abgrall
2014-06-13 23:41 ` Theodore Ts'o
2014-06-14 0:46 ` JP Abgrall
2014-06-17 2:49 ` Dave Chinner
2014-06-17 11:27 ` Theodore Ts'o
2014-06-17 11:55 ` Lukáš Czerner
2014-06-17 12:46 ` Theodore Ts'o
2014-06-17 13:00 ` Lukáš Czerner
2014-06-17 13:54 ` Theodore Ts'o
2014-06-17 17:53 ` JP Abgrall
2014-06-18 9:33 ` Lukáš Czerner
2014-06-18 21:51 ` JP Abgrall
2014-06-19 8:10 ` Lukáš Czerner
2014-06-18 22:06 ` Theodore Ts'o [this message]
2014-06-19 0:36 ` Dave Chinner
2014-06-19 8:15 ` Lukáš Czerner
2014-06-20 2:44 ` Martin K. Petersen
2014-06-19 8:33 ` Lukáš Czerner
2014-06-17 17:35 ` JP Abgrall
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=20140618220601.GA5114@thunk.org \
--to=tytso@mit.edu \
--cc=david@fromorbit.com \
--cc=gcondra@google.com \
--cc=jpa@google.com \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=sandeen@redhat.com \
/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).