From: Theodore Ts'o <tytso@mit.edu>
To: Dave Chinner <david@fromorbit.com>
Cc: JP Abgrall <jpa@google.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: Fri, 13 Jun 2014 10:20:54 -0400 [thread overview]
Message-ID: <20140613142054.GA23180@thunk.org> (raw)
In-Reply-To: <20140613050703.GT4453@dastard>
On Fri, Jun 13, 2014 at 03:07:03PM +1000, Dave Chinner wrote:
> >
> > Arg. So, if understand this correctly, if the eMMC chip won't get a
> > secure discard/trim of a block that gets reassigned to the FS, then
> ^^ within
>
> > data duplicates within the eMMC related to that block are not cleared,
> > and the next SFITRIM won't even reach that block or the duplicates as
> > the FS says they are in use.
>
> Pretty much.
If you really want this to work, and be 100% secure, you really need
to do the secure discard at the file system layer. The file system
could make sure that every single block gets a secure discard before
it gets reused. Now as long as you can be sure the flash controller
won't discard certain trims because the range is too small or the
flash controller is too busy (DISCARD is "advisory" which means the
flash controller is free to drop any discard request on the floor; you
should check and see if secure discard is a similarly advisory
request. Yes, that would be broken, but the flash controller
developers leaned on the standards bodies to make discard_zeros_data
to be similarly useless.)
One question --- do you really need to use secure discard on all
blocks, or just on certain critical bits of data? If so, there may be
other ways of meeting your security requirements. One of the things
which Michael Halcrow has been implementing for filesystem level
encryption for ChromeOS, so that selecting ext4 files can be encrypted
using per-user keys. He recently has gotten his proof of concept
working with a global fixed key, so he's pretty far along. (Although
I'm sure we'll need to do quite a bit of cleanup before it will be
ready for upstream submission.) Depending on what your security
requirements are, perhaps this might help meet your security
requirements.
Feel free to contact Michael and I at our google.com e-mails and
perhaps schedule a meeting if that would be helpful.
Cheers,
- Ted
next prev parent reply other threads:[~2014-06-13 14:20 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 [this message]
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
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=20140613142054.GA23180@thunk.org \
--to=tytso@mit.edu \
--cc=david@fromorbit.com \
--cc=gcondra@google.com \
--cc=jpa@google.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).