From: Jarkko Sakkinen <jarkko@kernel.org>
To: Stefano Garzarella <sgarzare@redhat.com>
Cc: Peter Huewe <peterhuewe@gmx.de>,
Tom Lendacky <thomas.lendacky@amd.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Borislav Petkov <bp@alien8.de>,
linux-integrity@vger.kernel.org,
Dov Murik <dovmurik@linux.ibm.com>,
Dionna Glaze <dionnaglaze@google.com>,
linux-coco@lists.linux.dev,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Claudio Carvalho <cclaudio@linux.ibm.com>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Joerg Roedel <jroedel@suse.de>
Subject: Re: [PATCH v3 2/4] svsm: add header with SVSM_VTPM_CMD helpers
Date: Tue, 11 Mar 2025 12:07:55 +0200 [thread overview]
Message-ID: <Z9ALe-kPZ5o_pim7@kernel.org> (raw)
In-Reply-To: <20250311094225.35129-3-sgarzare@redhat.com>
On Tue, Mar 11, 2025 at 10:42:23AM +0100, Stefano Garzarella wrote:
> Helpers for the SVSM_VTPM_CMD calls used by the vTPM protocol defined by
> the AMD SVSM spec [1].
>
> The vTPM protocol follows the Official TPM 2.0 Reference Implementation
> (originally by Microsoft, now part of the TCG) simulator protocol.
>
> [1] "Secure VM Service Module for SEV-SNP Guests"
> Publication # 58019 Revision: 1.00
>
> Co-developed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> Co-developed-by: Claudio Carvalho <cclaudio@linux.ibm.com>
> Signed-off-by: Claudio Carvalho <cclaudio@linux.ibm.com>
> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
> ---
> v3:
> - renamed header and prefix to make clear it's related to the SVSM vTPM
> protocol
> - renamed fill/parse functions [Tom]
> - removed link to the spec because those URLs are unstable [Borislav]
> ---
> include/linux/svsm_vtpm.h | 141 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 141 insertions(+)
> create mode 100644 include/linux/svsm_vtpm.h
>
> diff --git a/include/linux/svsm_vtpm.h b/include/linux/svsm_vtpm.h
> new file mode 100644
> index 000000000000..2ce9b1cb827e
> --- /dev/null
> +++ b/include/linux/svsm_vtpm.h
> @@ -0,0 +1,141 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2023 James.Bottomley@HansenPartnership.com
> + * Copyright (C) 2025 Red Hat, Inc. All Rights Reserved.
> + *
> + * Helpers for the SVSM_VTPM_CMD calls used by the vTPM protocol defined by the
> + * AMD SVSM spec [1].
> + *
> + * The vTPM protocol follows the Official TPM 2.0 Reference Implementation
> + * (originally by Microsoft, now part of the TCG) simulator protocol.
> + *
> + * [1] "Secure VM Service Module for SEV-SNP Guests"
> + * Publication # 58019 Revision: 1.00
> + */
> +#ifndef _SVSM_VTPM_H_
> +#define _SVSM_VTPM_H_
> +
> +#include <linux/errno.h>
> +#include <linux/string.h>
> +#include <linux/types.h>
> +
> +/*
> + * The current TCG Simulator TPM commands we support. The complete list is
> + * in the TcpTpmProtocol header:
> + *
> + * https://github.com/TrustedComputingGroup/TPM/blob/main/TPMCmd/Simulator/include/TpmTcpProtocol.h
> + */
> +
> +#define TPM_SEND_COMMAND 8
> +#define TPM_SIGNAL_CANCEL_ON 9
> +#define TPM_SIGNAL_CANCEL_OFF 10
> +/*
> + * Any platform specific commands should be placed here and should start
> + * at 0x8000 to avoid clashes with the TCG Simulator protocol. They should
> + * follow the same self describing buffer format below.
> + */
> +
> +#define SVSM_VTPM_MAX_BUFFER 4096 /* max req/resp buffer size */
> +
Across the board below data structures: I'd svsm_vtpm_ prefix them.
The rational is quite practical: it would easier to grep them later
on.
> +/**
> + * struct tpm_req - generic request header for single word command
> + *
> + * @cmd: The command to send
> + */
> +struct tpm_req {
> + u32 cmd;
> +} __packed;
__packed is useless here.
> +
> +/**
> + * struct tpm_resp - generic response header
> + *
> + * @size: The response size (zero if nothing follows)
> + *
> + * Note: most TCG Simulator commands simply return zero here with no indication
> + * of success or failure.
> + */
> +struct tpm_resp {
> + u32 size;
> +} __packed;
Ditto.
> +
> +/**
> + * struct tpm_send_cmd_req - Structure for a TPM_SEND_COMMAND request
> + *
> + * @hdr: The request header whit the command (must be TPM_SEND_COMMAND)
> + * @locality: The locality
> + * @inbuf_size: The size of the input buffer following
> + * @inbuf: A buffer of size inbuf_size
> + *
> + * Note that TCG Simulator expects @inbuf_size to be equal to the size of the
> + * specific TPM command, otherwise an TPM_RC_COMMAND_SIZE error is
> + * returned.
> + */
> +struct tpm_send_cmd_req {
> + struct tpm_req hdr;
Useless nesting that makes this obfuscated: you can just as well put
that single field here, i.e.
u32 cmd;
> + u8 locality;
> + u32 inbuf_size;
> + u8 inbuf[];
Why not just buf?
> +} __packed;
Since we don't care about TCG Simulator compatibility I'd expect that
these are ordered in a way that they align nicely. E.g.,
struct svsm_vtpm_request {
u32 command;
u16 locality;
u16 buffer_size;
u8 buffer[];
};
64k should enough for any possible TPM command.
> +
> +/**
> + * struct tpm_send_cmd_req - Structure for a TPM_SEND_COMMAND response
> + *
> + * @hdr: The response header whit the following size
> + * @outbuf: A buffer of size hdr.size
> + */
> +struct tpm_send_cmd_resp {
> + struct tpm_resp hdr;
> + u8 outbuf[];
> +} __packed;
Why this does not have size? Here also __packed is useless even with the
pre-existing layout, and something like svsm_tpm_response would be a
factor more reasonable name.
> +
> +/**
> + * svsm_vtpm_fill_cmd_req() - fill a struct tpm_send_cmd_req to be sent to SVSM
> + * @req: The struct tpm_send_cmd_req to fill
> + * @locality: The locality
> + * @buf: The buffer from where to copy the payload of the command
> + * @len: The size of the buffer
> + *
> + * Return: 0 on success, negative error code on failure.
> + */
> +static inline int
> +svsm_vtpm_fill_cmd_req(struct tpm_send_cmd_req *req, u8 locality,
> + const u8 *buf, size_t len)
svsm_vtpm_fill_request()
> +{
> + if (len > SVSM_VTPM_MAX_BUFFER - sizeof(*req))
> + return -EINVAL;
> +
> + req->hdr.cmd = TPM_SEND_COMMAND;
> + req->locality = locality;
> + req->inbuf_size = len;
> +
> + memcpy(req->inbuf, buf, len);
> +
> + return 0;
> +}
> +
> +/**
> + * svsm_vtpm_parse_cmd_resp() - Parse a struct tpm_send_cmd_resp received from
> + * SVSM
> + * @resp: The struct tpm_send_cmd_resp to parse
> + * @buf: The buffer where to copy the response
> + * @len: The size of the buffer
> + *
> + * Return: buffer size filled with the response on success, negative error
> + * code on failure.
> + */
> +static inline int
> +svsm_vtpm_parse_cmd_resp(const struct tpm_send_cmd_resp *resp, u8 *buf,
> + size_t len)
svsm_vtpm_parse_response()
> +{
> + if (len < resp->hdr.size)
> + return -E2BIG;
> +
> + if (resp->hdr.size > SVSM_VTPM_MAX_BUFFER - sizeof(*resp))
> + return -EINVAL; // Invalid response from the platform TPM
> +
> + memcpy(buf, resp->outbuf, resp->hdr.size);
> +
> + return resp->hdr.size;
> +}
> +
> +#endif /* _SVSM_VTPM_H_ */
> --
> 2.48.1
>
BR, Jarkko
next prev parent reply other threads:[~2025-03-11 10:07 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-11 9:42 [PATCH v3 0/4] Enlightened vTPM support for SVSM on SEV-SNP Stefano Garzarella
2025-03-11 9:42 ` [PATCH v3 1/4] x86/sev: add SVSM vTPM probe/send_command functions Stefano Garzarella
2025-03-11 9:56 ` Jarkko Sakkinen
2025-03-12 10:56 ` Stefano Garzarella
2025-03-14 15:04 ` Jarkko Sakkinen
2025-03-14 15:27 ` Tom Lendacky
2025-03-17 13:36 ` Jarkko Sakkinen
2025-03-18 10:07 ` Stefano Garzarella
2025-03-20 15:03 ` Jarkko Sakkinen
2025-03-20 17:16 ` Borislav Petkov
2025-03-20 17:30 ` Jarkko Sakkinen
2025-03-21 9:01 ` Stefano Garzarella
2025-03-21 22:05 ` Borislav Petkov
2025-03-22 20:17 ` Jarkko Sakkinen
2025-03-24 9:00 ` Stefano Garzarella
2025-03-11 9:42 ` [PATCH v3 2/4] svsm: add header with SVSM_VTPM_CMD helpers Stefano Garzarella
2025-03-11 10:07 ` Jarkko Sakkinen [this message]
2025-03-12 11:47 ` Stefano Garzarella
2025-03-11 9:42 ` [PATCH v3 3/4] tpm: add SNP SVSM vTPM driver Stefano Garzarella
2025-03-14 16:48 ` Tom Lendacky
2025-03-17 13:43 ` Jarkko Sakkinen
2025-03-18 10:38 ` Stefano Garzarella
2025-03-18 14:54 ` Tom Lendacky
2025-03-18 16:18 ` Stefano Garzarella
2025-03-19 23:44 ` Jason Gunthorpe
2025-03-20 11:18 ` Stefano Garzarella
2025-03-20 15:00 ` Jarkko Sakkinen
2025-03-20 14:56 ` Jarkko Sakkinen
2025-03-11 9:42 ` [PATCH v3 4/4] x86/sev: register tpm-svsm platform device Stefano Garzarella
2025-03-14 16:56 ` Tom Lendacky
2025-03-17 13:34 ` Jarkko Sakkinen
2025-03-18 10:44 ` Stefano Garzarella
2025-03-20 15:02 ` Jarkko Sakkinen
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=Z9ALe-kPZ5o_pim7@kernel.org \
--to=jarkko@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=bp@alien8.de \
--cc=cclaudio@linux.ibm.com \
--cc=dave.hansen@linux.intel.com \
--cc=dionnaglaze@google.com \
--cc=dovmurik@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=jgg@ziepe.ca \
--cc=jroedel@suse.de \
--cc=linux-coco@lists.linux.dev \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterhuewe@gmx.de \
--cc=sgarzare@redhat.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
/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).