Hacker News Reader

Comment by trasz | Hacker News Reader

If not supporting WRITE SAME turns out to be a security issue, it's a bug in the operating system.

And yes, some filesystems do - ESX, for example, uses what they call VAAI, which is a set of optional (standardized) SCSI functionality, like WRITE SAME, COMPARE AND SWAP (iirc), and server side copy.

View on HN

Ah, blame tennis, my favorite game!

Is there an alternative non-optional strategy for achieving secure delete (or revocation semantics of some kind)? If not, this is a fundamental capability that you can't paper over by slapping an abstraction layer on top any more than you could turn a 1TB HDD into a 2TB HDD with an abstraction layer. If so, it seems to me like the bug is very much in the hard drive / standards, not in the operating system.

> Is there an alternative non-optional strategy for achieving secure delete

Issue normal data writes of blocks that are filled with zeros. The same way regular data makes it to the drive just fine will also of course work for data that's all zeros.

Oh, so WRITE SAME doesn't come with "no wear leveling" semantics? That makes emulation much more reasonable.

I think the only way to get "no wear leveling" is the ATA Secure Erase command. Which you only need for devices that do wear leveling in the first place which the drive in question doesn't anyway so it's a bit moot.

Would that work on a filesystem that supports sparse files?

We're talking about the filesystem driver itself issuing the write.

The above is a discussion about whether the filesystem driver or the block device driver would issue the SCSI commands.

This would never happen from userspace.

Why would you need to overwrite blocks of a sparse file? Which blocks would you be overwriting?

> If not supporting WRITE SAME turns out to be a security issue, it's a bug in the operating system.

Is it though? There is probably a big drawback in terms of resource consumption if this is not supported. Not all environments may be ok with this.

That sounds like a performance issue, not a security issue?

The (potential) security issue is that the operating system fails to clear disk space, possibly incorrectly assuming it has actually been cleared.

Except that it receives an error, so if it's assuming that, it's wrong.

This command is not mandated to be supported. Therefore, if an OS assumes it is supported, that's an OS problem, not the drive.

I don't see how this could occur. Either you do WRITE SAME and it works or it doesn't and you have to manually issue WRITE commands.

Reply on news.ycombinator.com