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 86D5BCDB465 for ; Mon, 16 Oct 2023 08:55:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233108AbjJPIzH (ORCPT ); Mon, 16 Oct 2023 04:55:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60120 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232997AbjJPIzF (ORCPT ); Mon, 16 Oct 2023 04:55:05 -0400 Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 55CD5AB for ; Mon, 16 Oct 2023 01:55:03 -0700 (PDT) Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id B1E5A240104 for ; Mon, 16 Oct 2023 10:55:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1697446500; bh=lcNO8RF8USGnm28CYJPW25RzcPZaulI87Ufu5MZHyDw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:From: Content-Transfer-Encoding:From; b=jNLOewiDEgdZnDPeEfYUIhkZbGReuru7naU2nd7Heeezn0Gc1HZUYupFHyg3vY/Zo +A1rhac77W+buyP/lUB2Ev0FvzHDw8rd/TvzGFIgU6+IjFAwEInF2Tu5+SqW0oprAY Ff7WGYU6Gy5Nl4NSEYIbRIdEB8X+EcrEg09R4+g1v40fokppYEZXKLyviJ8yE0/GxM 6TINvIoFFHoO8YfLAzmYb3IJPkOCVpqKx+M5b07wco+bjmWiicJ9kBgsitDzkmRLxU Z/N3yHD5RjslV3S7gy0nnfPt7hJ9teY4PTiKxbctfRrdH41VDHbaO2w1Z9RGMwKYsx EEsSiJPVuqNIw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4S89st09KMz9rxY; Mon, 16 Oct 2023 10:54:57 +0200 (CEST) Message-ID: <7e3e0394-c644-4f7c-b7c8-849d459b3931@posteo.net> Date: Mon, 16 Oct 2023 08:54:57 +0000 MIME-Version: 1.0 Subject: Re: [PATCH 1/2] nvme-auth: use transformed key size to create resp Content-Language: en-US To: Hannes Reinecke , linux-kernel@vger.kernel.org Cc: linux-nvme@lists.infradead.org, sagi@grimberg.me, hch@lst.de, axboe@kernel.dk, kbusch@kernel.org, Akash Appaiah References: <20231013202827.2262708-1-shiftee@posteo.net> <20231013202827.2262708-2-shiftee@posteo.net> From: Mark O'Donovan In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14/10/2023 12:41, Hannes Reinecke wrote: > On 10/13/23 22:28, Mark O'Donovan wrote: >> This does not change current behaviour as the driver currently >> verifies that the secret size is the same size as the length of >> the transformation hash. >> >> Co-developed-by: Akash Appaiah >> Signed-off-by: Akash Appaiah >> Signed-off-by: Mark O'Donovan >> --- >>   drivers/nvme/host/auth.c | 11 ++++++++++- >>   1 file changed, 10 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/nvme/host/auth.c b/drivers/nvme/host/auth.c >> index daf5d144a8ea..e7d478d17b06 100644 >> --- a/drivers/nvme/host/auth.c >> +++ b/drivers/nvme/host/auth.c >> @@ -418,6 +418,14 @@ static int nvme_auth_set_dhchap_failure2_data(struct nvme_ctrl *ctrl, >>       return size; >>   } >> +static int nvme_auth_dhchap_transformed_key_len(struct nvme_dhchap_key *key) >> +{ >> +    if (key->hash) >> +        return nvme_auth_hmac_hash_len(key->hash); >> + >> +    return key->len; >> +} >> + >>   static int nvme_auth_dhchap_setup_host_response(struct nvme_ctrl *ctrl, >>           struct nvme_dhchap_queue_context *chap) >>   { >> @@ -442,7 +450,8 @@ static int nvme_auth_dhchap_setup_host_response(struct nvme_ctrl *ctrl, >>       } >>       ret = crypto_shash_setkey(chap->shash_tfm, >> -            chap->host_response, ctrl->host_key->len); >> +            chap->host_response, >> +            nvme_auth_dhchap_transformed_key_len(ctrl->host_key)); >>       if (ret) { >>           dev_warn(ctrl->device, "qid %d: failed to set key, error %d\n", >>                chap->qid, ret); > > Hmm. Yeah, hash size vs secret size always gets me. > However, wouldn't it be better to return the key size from > nvme_auth_transform_key and us that directly? > (cf the attached patch) > > Cheers, > > Hannes Hi Hannes, I gave this a try and it ended up being easier to put it in struct nvme_dhchap_key. V2 also does the nvme target code, and this means the length is stored in the same place. Let me know if this works for you. Thanks, Mark