qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Wilfred Mallawa <wilfred.mallawa@wdc.com>
To: "jonathan.cameron@huawei.com" <jonathan.cameron@huawei.com>
Cc: "its@irrelevant.dk" <its@irrelevant.dk>,
	"hreitz@redhat.com" <hreitz@redhat.com>,
	Alistair Francis <Alistair.Francis@wdc.com>,
	"philmd@linaro.org" <philmd@linaro.org>,
	"stefanha@redhat.com" <stefanha@redhat.com>,
	"fam@euphon.net" <fam@euphon.net>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"foss@defmacro.it" <foss@defmacro.it>,
	"kwolf@redhat.com" <kwolf@redhat.com>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
	"mst@redhat.com" <mst@redhat.com>,
	"kbusch@kernel.org" <kbusch@kernel.org>,
	"marcel.apfelbaum@gmail.com" <marcel.apfelbaum@gmail.com>,
	"dlemoal@kernel.org" <dlemoal@kernel.org>
Subject: Re: [PATCH v4 3/5] hw/nvme: add NVMe Admin Security SPDM support
Date: Tue, 9 Sep 2025 01:16:43 +0000	[thread overview]
Message-ID: <0242ecdeeeedc69689d71dd76d01459e191670f0.camel@wdc.com> (raw)
In-Reply-To: <20250904112205.00007e47@huawei.com>

On Thu, 2025-09-04 at 11:22 +0100, Jonathan Cameron wrote:
> On Thu,  4 Sep 2025 13:10:57 +1000
> Wilfred Mallawa <wilfred.opensource@gmail.com> wrote:
> 
> > From: Wilfred Mallawa <wilfred.mallawa@wdc.com>
> > 
> > Adds the NVMe Admin Security Send/Receive command support with
> > support
> > for DMTFs SPDM. The transport binding for SPDM is defined in the
> > DMTF DSP0286.
> > 
> > Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
> Hi Wilfred, 
> 
> I haven't even opened the nvme spec on basis others are covering that
> part well. So this is just a review based on the code in this patch
> so mostly style stuff.
> 
> Jonathan
> 
Hey Jonathan,

Sounds good! Thanks for the review. Comments inline.

Regards,
Wilfred
> > ---
> >  hw/nvme/ctrl.c       | 213
> > ++++++++++++++++++++++++++++++++++++++++++-
> >  hw/nvme/nvme.h       |   5 +
> >  include/block/nvme.h |  15 +++
> >  3 files changed, 232 insertions(+), 1 deletion(-)
> > 
> > diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c
> > index f5ee6bf260..df72599bcc 100644
> > --- a/hw/nvme/ctrl.c
> > +++ b/hw/nvme/ctrl.c
> > @@ -282,6 +282,8 @@ static const uint32_t nvme_cse_acs_default[256]
> > = {
> >      [NVME_ADM_CMD_FORMAT_NVM]       = NVME_CMD_EFF_CSUPP |
> > NVME_CMD_EFF_LBCC,
> >      [NVME_ADM_CMD_DIRECTIVE_RECV]   = NVME_CMD_EFF_CSUPP,
> >      [NVME_ADM_CMD_DIRECTIVE_SEND]   = NVME_CMD_EFF_CSUPP,
> > +    [NVME_ADM_CMD_SECURITY_SEND]   = NVME_CMD_EFF_CSUPP,
> > +    [NVME_ADM_CMD_SECURITY_RECV]   = NVME_CMD_EFF_CSUPP,
> 
> Maybe it's an email thing but that alignment of = looks off by one
> space.
Not email, will fix!
> 
> >  };
> >  
> >  static const uint32_t nvme_cse_iocs_nvm_default[256] = {
> > @@ -7282,6 +7284,210 @@ static uint16_t nvme_dbbuf_config(NvmeCtrl
> > *n, const NvmeRequest *req)
> >      return NVME_SUCCESS;
> >  }
> >  
> > +static uint16_t nvme_sec_prot_spdm_send(NvmeCtrl *n, NvmeRequest
> > *req)
> > +{
> > +    StorageSpdmTransportHeader hdr = {0};
> > +    g_autofree uint8_t *sec_buf = NULL;
> > +    uint32_t transfer_len = le32_to_cpu(req->cmd.cdw11);
> > +    uint32_t transport_transfer_len = transfer_len;
> > +    uint32_t dw10 = le32_to_cpu(req->cmd.cdw10);
> > +    uint32_t recvd;
> > +    uint16_t nvme_cmd_status, ret;
> > +    uint8_t secp = extract32(dw10, 24, 8);
> > +    uint8_t spsp1 = extract32(dw10, 16, 8);
> > +    uint8_t spsp0 = extract32(dw10, 8, 8);
> 
> See below. 16 bit field seems more logical to me.
> 
> > +    bool spdm_res;
> > +
> > +    if (transport_transfer_len > UINT32_MAX - sizeof(hdr)) {
> > +        return NVME_INVALID_FIELD | NVME_DNR;
> > +    }
> > +
> > +    transport_transfer_len += sizeof(hdr);
> > +    if (transport_transfer_len >
> > SPDM_SOCKET_MAX_MESSAGE_BUFFER_SIZE) {
> > +        return NVME_INVALID_FIELD | NVME_DNR;
> > +    }
> > +
> > +    ret = nvme_check_mdts(n, transport_transfer_len);
> > +    if (ret != NVME_SUCCESS) {
> > +        return ret;
> > +    }
> > +
> > +    /* Generate the NVMe transport header */
> > +    hdr.security_protocol = secp;
> > +    hdr.security_protocol_specific = cpu_to_le16((spsp1 << 8) |
> > spsp0);
> > +    hdr.length = cpu_to_le32(transfer_len);
> > +
> > +    sec_buf = g_try_malloc0(transport_transfer_len);
> > +    if (!sec_buf) {
> > +        return NVME_INTERNAL_DEV_ERROR;
> > +    }
> > +
> > +    /* Attach the transport header */
> > +    memcpy(sec_buf, &hdr, sizeof(hdr));
> > +    ret = nvme_h2c(n, sec_buf + sizeof(hdr), transfer_len, req);
> > +    if (ret) {
> > +        return ret;
> > +    }
> > +
> > +    spdm_res = spdm_socket_send(n->spdm_socket,
> > SPDM_SOCKET_STORAGE_CMD_IF_SEND,
> > +                                SPDM_SOCKET_TRANSPORT_TYPE_NVME,
> > sec_buf,
> > +                                transport_transfer_len);
> > +    if (!spdm_res) {
> > +        return NVME_DATA_TRAS_ERROR | NVME_DNR;
> > +    }
> > +
> > +    /* The responder shall ack with message status */
> > +    recvd = spdm_socket_receive(n->spdm_socket,
> > SPDM_SOCKET_TRANSPORT_TYPE_NVME,
> > +                                (uint8_t *)&nvme_cmd_status,
> 
> As in earlier patch, spdm_socket_receive() seems to take a void * so
> no cast
> should be needed and definitely not to a uint8_t *!
Ah yeah, will fixup.
> 
> > +                                SPDM_SOCKET_MAX_MSG_STATUS_LEN);
> > +
> > +    nvme_cmd_status = be16_to_cpu(nvme_cmd_status);
> > +
> > +    if (recvd < SPDM_SOCKET_MAX_MSG_STATUS_LEN) {
> > +        return NVME_DATA_TRAS_ERROR | NVME_DNR;
> > +    }
> > +
> > +    return nvme_cmd_status;
> > +}
> > +
> > +/* From host to controller */
> > +static uint16_t nvme_security_send(NvmeCtrl *n, NvmeRequest *req)
> > +{
> > +    uint32_t dw10 = le32_to_cpu(req->cmd.cdw10);
> > +    uint8_t secp = (dw10 >> 24) & 0xff;
> 
> Used extract32() below. Why not for this one?
Missed it! Will fixup :).
> 
> > +
> > +    switch (secp) {
> > +    case NVME_SEC_PROT_DMTF_SPDM:
> > +        if (n->spdm_socket <= 0) {
> > +            return NVME_INVALID_FIELD | NVME_DNR;
> > +        }
> > +        return nvme_sec_prot_spdm_send(n, req);
> > +    default:
> > +        /* Unsupported Security Protocol Type */
> > +        return NVME_INVALID_FIELD | NVME_DNR;
> > +    }
> > +
> > +    return NVME_INVALID_FIELD | NVME_DNR;
> > +}
> > +
> > +static uint16_t nvme_sec_prot_spdm_receive(NvmeCtrl *n,
> > NvmeRequest *req)
> > +{
> > +    StorageSpdmTransportHeader hdr;
> > +    g_autofree uint8_t *rsp_spdm_buf = NULL;
> > +    uint32_t dw10 = le32_to_cpu(req->cmd.cdw10);
> > +    uint32_t alloc_len = le32_to_cpu(req->cmd.cdw11);
> > +    uint32_t recvd, spdm_res;
> > +    uint16_t nvme_cmd_status, ret;
> > +    uint8_t secp = extract32(dw10, 24, 8);
> > +    uint8_t spsp1 = extract32(dw10, 16, 8);
> > +    uint8_t spsp0 = extract32(dw10, 8, 8);
> 
> This is a little odd. You break out two 8 bit fields here just
> to combine them again below.  Why not a 16bit field?
> If its about spec alignment maybe call that field spsp0_1
> 
Ah yeah, I think I split it out from when DSP0286 was WIP and it seemed
like we may need to parse SPSP here. But doesn't seem to be case, at-
least for now.
> 
> > +
> > +    if (!alloc_len) {
> > +        return NVME_INVALID_FIELD | NVME_DNR;
> > +    }
> > +
> > +    /* Generate the NVMe transport header */
> > +    hdr = (StorageSpdmTransportHeader) {
> > +        .security_protocol = secp,
> > +        .security_protocol_specific = cpu_to_le16((spsp1 << 8) |
> > spsp0),
> > +        .length = cpu_to_le32(alloc_len),
> > +    };
> > +
> > +    /* Forward if_recv to the SPDM Server with SPSP0 */
> > +    spdm_res = spdm_socket_send(n->spdm_socket,
> > SPDM_SOCKET_STORAGE_CMD_IF_RECV,
> > +                                SPDM_SOCKET_TRANSPORT_TYPE_NVME,
> > +                                (uint8_t *)&hdr, sizeof(hdr));
> 
> As above.
> 
> > +    if (!spdm_res) {
> > +        return NVME_DATA_TRAS_ERROR | NVME_DNR;
> > +    }
> > +
> > +    /* The responder shall ack with message status */
> > +    recvd = spdm_socket_receive(n->spdm_socket,
> > SPDM_SOCKET_TRANSPORT_TYPE_NVME,
> > +                                (uint8_t *)&nvme_cmd_status,
> 
> As above - seems to be a spurious cast.
> 
Will fixup for next version.

Cheers,
Wilfred
> 
> 

  reply	other threads:[~2025-09-09  1:17 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-04  3:10 [PATCH v4 0/5] NVMe: Add SPDM over the storage transport support Wilfred Mallawa
2025-09-04  3:10 ` [PATCH v4 1/5] spdm-socket: add seperate send/recv functions Wilfred Mallawa
2025-09-04 10:10   ` Jonathan Cameron via
2025-09-09  0:41     ` Wilfred Mallawa
2025-09-04  3:10 ` [PATCH v4 2/5] spdm: add spdm storage transport virtual header Wilfred Mallawa
2025-09-04  3:10 ` [PATCH v4 3/5] hw/nvme: add NVMe Admin Security SPDM support Wilfred Mallawa
2025-09-04 10:22   ` Jonathan Cameron via
2025-09-09  1:16     ` Wilfred Mallawa [this message]
2025-09-04 19:47   ` Stefan Hajnoczi
2025-09-04 19:50   ` Stefan Hajnoczi
2025-09-09  4:31     ` Wilfred Mallawa
2025-09-04  3:10 ` [PATCH v4 4/5] spdm: define SPDM transport enum types Wilfred Mallawa
2025-09-04 10:24   ` Jonathan Cameron via
2025-09-04  3:10 ` [PATCH v4 5/5] hw/nvme: connect SPDM over NVMe Security Send/Recv Wilfred Mallawa
2025-09-04 10:31   ` Jonathan Cameron via
2025-09-09  1:38     ` Wilfred Mallawa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0242ecdeeeedc69689d71dd76d01459e191670f0.camel@wdc.com \
    --to=wilfred.mallawa@wdc.com \
    --cc=Alistair.Francis@wdc.com \
    --cc=dlemoal@kernel.org \
    --cc=fam@euphon.net \
    --cc=foss@defmacro.it \
    --cc=hreitz@redhat.com \
    --cc=its@irrelevant.dk \
    --cc=jonathan.cameron@huawei.com \
    --cc=kbusch@kernel.org \
    --cc=kwolf@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).