On Wed, Jul 13, 2022 at 01:17:56PM +0100, Matthew Wilcox wrote: > The firmware needs to prove to me that it *did something*. That it > actually read those bytes that it claims to have verified. The simplest > way to do so is to calculate a hash over the blocks which were read > (maybe the host needs to provide a nonce as part of the VERIFY command > so the drive can't "remember" the checksum). >From a protocol perspective, NVMe's verify command currently leaves 8-bytes in the response unused, so this could be a reasonable way to return something like a crc64 of the verified blocks. The verify command starts at an arbitrary block and spans an arbitrary number of them, so I think a device "remembering" all possible combinations as a way to cheat may be harder than just doing the work :). But this is just theoretical; it'd be some time before we'd see devices supporting such a scheme, assuming there's support from the standards committees.
