On Fri, Jun 13, 2014 at 7:31 AM, Theodore Ts'o <tytso@xxxxxxx> wrote: > On Fri, Jun 13, 2014 at 10:20:54AM -0400, Theodore Ts'o wrote: >> >> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
