From: Wilfred Mallawa <wilfred.opensource@gmail.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: "Alistair Francis" <alistair.francis@wdc.com>,
"Keith Busch" <kbusch@kernel.org>,
"Klaus Jensen" <its@irrelevant.dk>,
"Jesper Devantier" <foss@defmacro.it>,
"Fam Zheng" <fam@euphon.net>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Kevin Wolf" <kwolf@redhat.com>,
"Hanna Reitz" <hreitz@redhat.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org,
"Jonathan Cameron" <Jonathan.Cameron@huawei.com>
Subject: Re: [PATCH v3 3/5] hw/nvme: add NVMe Admin Security SPDM support
Date: Thu, 04 Sep 2025 12:56:08 +1000 [thread overview]
Message-ID: <e1b88c82b1a8687b0e91c01df808a51b982a3bef.camel@gmail.com> (raw)
In-Reply-To: <20250903024705.GA103624@fedora>
On Tue, 2025-09-02 at 22:47 -0400, Stefan Hajnoczi wrote:
> On Mon, Sep 01, 2025 at 01:47:58PM +1000, Wilfred Mallawa wrote:
> >
[snip]
> > +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);
> > + bool spdm_res;
> > +
> > + transport_transfer_len += sizeof(hdr);
> > + if (transport_transfer_len >
> > SPDM_SOCKET_MAX_MESSAGE_BUFFER_SIZE) {
>
> An integer overflow check is needed since transfer_len comes from the
> untrusted guest. This will prevent the sec_buf buffer overflow below
> when nvme_h2c() is called.
Ah yeah, good catch! I will fixup in V4.
>
> > + return NVME_INVALID_FIELD | NVME_DNR;
> > + }
> > +
> > + /* 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_malloc0(transport_transfer_len);
>
> g_try_malloc0() is safer when using untrusted input from the guest.
> g_malloc0() aborts the process on failure, so it's disruptive.
> g_try_malloc0() allows you to handle allocation failures.
>
okay, that sounds alot better. Will switch to that.
> > +
> > + /* 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,
> > + SPDM_SOCKET_MAX_MSG_STATUS_LEN);
> > +
> > + nvme_cmd_status = cpu_to_be16(nvme_cmd_status);
>
> be16_to_cpu()?
Yeah it should be!
>
> >
[snip]
> > + nvme_cmd_status = cpu_to_be16(nvme_cmd_status);
>
> Should this be be16_to_cpu()?
Yep, it should be. Thanks!
>
> > + /* An error here implies the prior if_recv from requester was
> > spurious */
> > + if (nvme_cmd_status != NVME_SUCCESS) {
> > + return nvme_cmd_status;
> > + }
> > +
> > + /* Clear to start receiving data from the server */
> > + rsp_spdm_buf = g_malloc0(alloc_len);
>
> g_try_malloc0().
Thanks!
Wilfred
>
next prev parent reply other threads:[~2025-09-04 2:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-01 3:47 [PATCH v2 0/5] NVMe: Add SPDM over the storage transport support Wilfred Mallawa
2025-09-01 3:47 ` [PATCH v3 1/5] spdm-socket: add seperate send/recv functions Wilfred Mallawa
2025-09-01 3:47 ` [PATCH v3 2/5] spdm: add spdm storage transport virtual header Wilfred Mallawa
2025-09-01 3:47 ` [PATCH v3 3/5] hw/nvme: add NVMe Admin Security SPDM support Wilfred Mallawa
2025-09-03 2:47 ` Stefan Hajnoczi
2025-09-03 9:42 ` Klaus Jensen
2025-09-04 2:57 ` Wilfred Mallawa
2025-09-04 2:56 ` Wilfred Mallawa [this message]
2025-09-03 10:01 ` Klaus Jensen
2025-09-04 2:58 ` Wilfred Mallawa
2025-09-01 3:47 ` [PATCH v3 4/5] spdm: define SPDM transport enum types Wilfred Mallawa
2025-09-01 3:48 ` [PATCH v3 5/5] hw/nvme: connect SPDM over NVMe Security Send/Recv 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=e1b88c82b1a8687b0e91c01df808a51b982a3bef.camel@gmail.com \
--to=wilfred.opensource@gmail.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=alistair.francis@wdc.com \
--cc=fam@euphon.net \
--cc=foss@defmacro.it \
--cc=hreitz@redhat.com \
--cc=its@irrelevant.dk \
--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).