On Wed, Jun 18, 2014 at 06:06:01PM -0400, Theodore Ts'o wrote: > On Wed, Jun 18, 2014 at 11:33:47AM +0200, Lukáš Czerner wrote: > > And I have no illusion that those are the only ones that does not > > work. This hardware can not be trusted and this must not be > > advertised as a security feature. > > There's always crappy hardware out there. If that's true, should then > not call ATA Secure Erase by that term because somewhere out there, > there will be an incompetently implemented SSD that doesn't do the > right thing with ATA Secure Erase? I just don't think that's > particularly useful. If the command is called "secure erase" or > "secure discard" in the specification, then that's what we should use, > just to avoid confusion if nothing else. That's just a steaming pile of rhetoric. If that was true, then we wouldn't be calling our operations BLKDISCARD or "discard", would we? It would be called "TRIM" or "WRITE_SAME" because that's what the device layer standards call the operations. Sure, we have a "FITRIM" ioctl, but we acknowledged early on that it was badly named because different protocols use different names. That's why we started to use "discard" instead - it's a protocol and device neutral term that describes the intent of the operation - to -discard blocks-. IOWs, I think that Lukas is right on the money here - we should not imply something is secure when it is not, nor should we name high level interfaces based on the standardise name on the low level primitive some class of device or protocol uses. Rather, we should describe it for what it is: it is a command to *scrub the data* from a range of blocks. i.e. it's not a discard operation at all - it's a "scrub" operation that we are asking the device to perform. And further, scrubbing has a specific meaning in the security environment - it doesn't imply security - it just means there is a mechanism for physically removing data from it's known locations. Security comes from what you do with the scrubbing mechanism at higher layers. Scrubbing is something people already understand and it's clear that it's a data manipulation operation and not some magic "secure" operation. And by calling it "scrub" we get away from the idea that it only works on specific hardware - hardware acceleration is good, but there's no reason why we should design the functionality to only be useful on systems with hardware scrubbing capability... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
