From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CBCB0CCA480 for ; Wed, 13 Jul 2022 14:04:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235692AbiGMOER (ORCPT ); Wed, 13 Jul 2022 10:04:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39320 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236348AbiGMOEM (ORCPT ); Wed, 13 Jul 2022 10:04:12 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7500330F62; Wed, 13 Jul 2022 07:04:11 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 329CAB81FC6; Wed, 13 Jul 2022 14:04:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D0153C34114; Wed, 13 Jul 2022 14:04:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657721049; bh=ZAU0L5kK4Sf9McbG926Hj/XUT0R01MpGmbcgsJYk0eo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JfznMmDaQH8d32YdV1e+uqSCeYmXGCrB04FZaz89S34KHt+hYUNSByGZqfuyt8WaJ OXEs5vq9mIuJZVjZSfiO3VQGq17tu956YqCQYKrTviTMbGlc/FmaBatE1ij2Un8cJu ma92AqTrKLaKbwKsTf3ddF93RILXggb102oGrWXD7NNZjvJ0hxyvCPlaUMGd3Ubtz/ P+fi5Q43yiUn4WjZ/LMf/PljTOCIuc0JYEQpQedQnEJpRE9jzeed85Y7qufijypS2/ Q46HfTgC5K/9xlwN6PWBZk/CAVeoGTHOEELqfB+2XjR98j1PjCER8gYkAAQGulFCBe XpJ/yVKe1IYTA== Date: Wed, 13 Jul 2022 08:04:03 -0600 From: Keith Busch To: Matthew Wilcox Cc: Chaitanya Kulkarni , "linux-block@vger.kernel.org" , "linux-raid@vger.kernel.org" , "linux-nvme@lists.infradead.org" , "linux-fsdevel@vger.kernel.org" , "axboe@kernel.dk" , "agk@redhat.com" , "song@kernel.org" , "djwong@kernel.org" , "hch@lst.de" , "sagi@grimberg.me" , "jejb@linux.ibm.com" , "martin.petersen@oracle.com" , "viro@zeniv.linux.org.uk" , "javier@javigon.com" , "johannes.thumshirn@wdc.com" , "bvanassche@acm.org" , "dongli.zhang@oracle.com" , "ming.lei@redhat.com" , "jefflexu@linux.alibaba.com" , "josef@toxicpanda.com" , "clm@fb.com" , "dsterba@suse.com" , "jack@suse.com" , "tytso@mit.edu" , "adilger.kernel@dilger.ca" , "jlayton@kernel.org" , "idryomov@gmail.com" , "danil.kipnis@cloud.ionos.com" , "ebiggers@google.com" , "jinpu.wang@cloud.ionos.com" Subject: Re: [PATCH 0/6] block: add support for REQ_OP_VERIFY Message-ID: References: <20220630091406.19624-1-kch@nvidia.com> <5ffe57d3-354c-eabe-ea38-9c4201c13970@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org 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.