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 -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
