On Fri, Jun 13, 2014 at 7:31 AM, Theodore Ts'o [off-list ref] wrote:

On Fri, Jun 13, 2014 at 10:20:54AM -0400, Theodore Ts'o wrote:

quoted

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.

BTW, one major downside of doing a secure trim after every time that a
block has been released is that it will massively increase the flash
wear, since if you do a secure trim on a single 4k block in 512k erase
block, assuming that secure trim has been implemented properly from a
security perspective, it will need to copy out all of the used portion
of the 512k erase block, and then erase it.

We did not plan on doing always-on secure-discard or always
secure-trim for those reasons.

This is one of the reasons why I asked if you really need to worry
about securely discarding all of the blocks on the file system, or
just blocks containing specific really security-sensitive information
(i.e., for Google Wallet, etc.)

Part of the "why" for this SFITRIM patch:
At some point we need to delete a bunch of files and packages and we
want to reduce the volume of recoverable data (file content, file
names, file names within databases or other files,...).
These are not security-critical files.
We understand that not all of the data can be purged, but covering
most of it would be nice.
We currently only care about ext4.
The current expected leftovers from a cleanup would be:
  - data blocks that were modified during the life-time of the files.
This includes directories containing those filenames.
  - file names in top level directories for directories that are not
getting deleted.
  - databases that are not set for deletion which referenced the files
being deleted.

If so, you might be better off either doing per-file encryption, or
per-file secure discard.

The per-file secure discard seems to be the way to go, as there are
only a few places in Android where this needs to be turned on.
The  current idletime-fstrim would  switch from FITRIM to SFITRIM to
reduce the leftovers.