[lkml]   [2010]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/2] fs: Do not dispatch FITRIM through separate super_operation
On Fri, Nov 19, 2010 at 10:50:03AM -0500, Christoph Hellwig wrote:
> It's a huge issue for virtualization, where naive TRIM implementations
> can expose data deleted in one VM to others. It's also a huge issues
> for RAIDs as mentioned by you.

Fair enough, I'll buy that. If you are sharing an SSD using
virtualization across two VM's with different trust bounaries,
non-deterministic TRIM could very well be an issue, depending on how
it the "non-deterministic" bit was implemented.

(I can think of one PCIe-attached flash implementation I know of where
the trim is simply not persistent across a power failure, such that if
Alice trims a block, it will return 0, but if no one rewrites the
block before a power failure, then reading that some block will return
Alice's original data, and not data belonging to Bob. This would be
an example of a non-deterministic TRIM that would be problematic for
RAID, but not from a security perspective. OTOH, the trim command is
blazingly fast on this implementation, since there is absolutely no
flash write or erase operation associated with the TRIM, and so mount
-o discard makes a lot of sense for this particular storage device.)

- Ted

 \ /
  Last update: 2010-11-19 17:19    [W:0.065 / U:1.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site