mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tom Lendacky <thomas.lendacky@amd.com>
To: Dionna Glaze <dionnaglaze@google.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Ashish Kalra <ashish.kalra@amd.com>,
	John Allen <john.allen@amd.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	Michael Roth <michael.roth@amd.com>,
	Borislav Petkov <bp@alien8.de>
Cc: linux-crypto@vger.kernel.org
Subject: Re: [PATCH v4 4/6] crypto: ccp: Add DOWNLOAD_FIRMWARE_EX support
Date: Tue, 5 Nov 2024 15:58:43 -0600	[thread overview]
Message-ID: <f6810eb0-3834-e5b4-6c1f-9422dfff5560@amd.com> (raw)
In-Reply-To: <20241105010558.1266699-5-dionnaglaze@google.com>

On 11/4/24 19:05, Dionna Glaze wrote:
> The DOWNLOAD_FIRMWARE_EX command requires cache flushing and introduces
> new error codes that could be returned to user space.
> 
> The function is in sev-dev.c rather than sev-fw.c to avoid exposing the
> __sev_do_cmd_locked function in the sev-dev.h header.

Please say "why" this is being added.

> 
> Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
> ---
>  drivers/crypto/ccp/sev-dev.c | 66 +++++++++++++++++++++++++++++++-----
>  include/linux/psp-sev.h      | 26 ++++++++++++++
>  include/uapi/linux/psp-sev.h |  5 +++
>  3 files changed, 89 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
> index 9265b6d534bbe..32f7b6147905e 100644
> --- a/drivers/crypto/ccp/sev-dev.c
> +++ b/drivers/crypto/ccp/sev-dev.c
> @@ -223,6 +223,7 @@ static int sev_cmd_buffer_len(int cmd)
>  	case SEV_CMD_SNP_GUEST_REQUEST:		return sizeof(struct sev_data_snp_guest_request);
>  	case SEV_CMD_SNP_CONFIG:		return sizeof(struct sev_user_data_snp_config);
>  	case SEV_CMD_SNP_COMMIT:		return sizeof(struct sev_data_snp_commit);
> +	case SEV_CMD_SNP_DOWNLOAD_FIRMWARE_EX:	return sizeof(struct sev_data_download_firmware_ex);
>  	default:				return 0;
>  	}
>  
> @@ -1597,14 +1598,7 @@ static int sev_update_firmware(struct device *dev)
>  		return -1;
>  	}
>  
> -	/*
> -	 * SEV FW expects the physical address given to it to be 32
> -	 * byte aligned. Memory allocated has structure placed at the
> -	 * beginning followed by the firmware being passed to the SEV
> -	 * FW. Allocate enough memory for data structure + alignment
> -	 * padding + SEV FW.
> -	 */
> -	data_size = ALIGN(sizeof(struct sev_data_download_firmware), 32);
> +	data_size = ALIGN(sizeof(struct sev_data_download_firmware), SEV_FW_ALIGNMENT);
>  
>  	order = get_order(firmware->size + data_size);
>  	p = alloc_pages(GFP_KERNEL, order);
> @@ -1645,6 +1639,62 @@ static int sev_update_firmware(struct device *dev)
>  	return ret;
>  }
>  
> +int sev_snp_download_firmware_ex(struct sev_device *sev, const u8 *data, u32 size, int *error)
> +{
> +	struct sev_data_download_firmware_ex *data_ex;
> +	int ret, order;
> +	struct page *p;
> +	u64 data_size;
> +	void *fw_dest;
> +
> +	data_size = ALIGN(sizeof(struct sev_data_download_firmware_ex),
> +			  SEV_FW_ALIGNMENT);

This can be a single line.

> +
> +	order = get_order(size + data_size);
> +	p = alloc_pages(GFP_KERNEL, order);
> +	if (!p)
> +		return -ENOMEM;
> +
> +	/*
> +	 * Copy firmware data to a kernel allocated contiguous
> +	 * memory region.
> +	 */
> +	data_ex = page_address(p);
> +	fw_dest = page_address(p) + data_size;
> +	memset(data_ex, 0, data_size);
> +	memcpy(fw_dest, data, size);
> +
> +	data_ex->address = __psp_pa(fw_dest);
> +	data_ex->len = size;
> +	data_ex->cmdlen = sizeof(struct sev_data_download_firmware_ex);
> +
> +	/*
> +	 * SNP_COMMIT should be issued explicitly to commit the updated
> +	 * firmware after guest context pages have been updated.
> +	 */
> +	ret = sev_do_cmd(SEV_CMD_SNP_DOWNLOAD_FIRMWARE_EX, data_ex, error);
> +

Remove blank line.

> +	if (ret)
> +		goto free_err;
> +
> +	__free_pages(p, order);

If you remove this...

> +
> +	/* Need to do a DF_FLUSH after live firmware update */
> +	wbinvd_on_all_cpus();
> +	ret = __sev_do_cmd_locked(SEV_CMD_SNP_DF_FLUSH, NULL, error);
> +	if (ret) {
> +		dev_dbg(sev->dev, "DF_FLUSH error %d\n", *error);
> +		goto fw_err;

and remove this...

> +	}
> +
> +	return 0;

... you can remove this return 0 statement and the fw_err label.

> +
> +free_err:
> +	__free_pages(p, order);
> +fw_err:
> +	return ret;
> +}
> +
>  static int __sev_snp_shutdown_locked(int *error, bool panic)
>  {
>  	struct psp_device *psp = psp_master;
> diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
> index 903ddfea85850..6a08c56cd9771 100644
> --- a/include/linux/psp-sev.h
> +++ b/include/linux/psp-sev.h
> @@ -16,6 +16,15 @@
>  
>  #define SEV_FW_BLOB_MAX_SIZE	0x4000	/* 16KB */
>  
> +/*
> + * SEV FW expects the physical address given to it to be 32
> + * byte aligned. Memory allocated has structure placed at the
> + * beginning followed by the firmware being passed to the SEV
> + * FW. Allocate enough memory for data structure + alignment
> + * padding + SEV FW.
> + */
> +#define SEV_FW_ALIGNMENT       32

Does this need to be in include/linux/psp-sev.h or can it go in
drivers/crypto/ccp/sev-dev.h ?

> +
>  /**
>   * SEV platform state
>   */
> @@ -185,6 +194,23 @@ struct sev_data_download_firmware {
>  	u32 len;				/* In */
>  } __packed;
>  
> +/**
> + * struct sev_data_download_firmware_ex - DOWNLOAD_FIRMWARE_EX command parameters
> + *
> + * @length: length of this command buffer
> + * @address: physical address of firmware image
> + * @len: len of the firmware image
> + * @commit: automatically commit the newly installed image
> + */
> +struct sev_data_download_firmware_ex {
> +	u32 cmdlen;				/* In */

This doesn't match the name above in the comment.

> +	u32 reserved;				/* In */
> +	u64 address;				/* In */
> +	u32 len;				/* In */
> +	u32 commit:1;				/* In */
> +	u32 reserved2:31;			/* In */

These names typically match what is in the spec, so I would expect to
see length, fw_paddr (or fw_address), and fw_len.

> +} __packed;
> +
>  /**
>   * struct sev_data_get_id - GET_ID command parameters
>   *
> diff --git a/include/uapi/linux/psp-sev.h b/include/uapi/linux/psp-sev.h
> index 832c15d9155bd..936464d4f282a 100644
> --- a/include/uapi/linux/psp-sev.h
> +++ b/include/uapi/linux/psp-sev.h
> @@ -80,6 +80,11 @@ typedef enum {
>  	SEV_RET_INVALID_PAGE_OWNER,
>  	SEV_RET_INVALID_PAGE_AEAD_OFLOW,
>  	SEV_RET_RMP_INIT_REQUIRED,
> +	SEV_RET_BAD_SVN,
> +	SEV_RET_BAD_VERSION,
> +	SEV_RET_SHUTDOWN_REQUIRED,
> +	SEV_RET_UPDATE_FAILED,
> +	SEV_RET_RESTORE_REQUIRED,

Hmmm... yeah, as Alexey mentioned, these return values are not correct.

SEV_RET_INVALID_PAGE_SIZE should follow SEV_RET_SECURE_DATA_INVALID

so "SEV_RET_INVALID_KEY = 0x27" should be moved after
SEV_RET_RMP_INIT_REQUIRED

and SEV_RET_RMP_INIT_REQUIRED should be = 0x20, since RB_MODE_EXITED is
0x1f.

And then you might as well include RMP_INIT_FAILED in the list.

The list should look like:

	...
	SEV_RET_SECURE_DATA_INVALID,
	SEV_RET_INVALID_PAGE_SIZE,
	SEV_RET_INVALID_PAGE_STATE,
	SEV_RET_INVALID_MDATA_ENTRY,
	SEV_RET_INVALID_PAGE_OWNER,
	SEV_RET_AEAD_OFLOW,
	SEV_RET_RB_MODE_EXITED,
	SEV_RET_RMP_INIT_REQUIRED,
	SEV_RET_BAD_SVN,
	SEV_RET_BAD_VERSION,
	SEV_RET_SHUTDOWN_REQUIRED,
	SEV_RET_UPDATE_FAILED,
	SEV_RET_RESTORE_REQUIRED,
	SEV_RET_RMP_INIT_FAILED,
	SEV_RET_INVALID_KEY,
	SEV_RET_MAX,

Of course this is already upstream in uapi, so I don't know how it is
supposed to be handled.

Thanks,
Tom

>  	SEV_RET_MAX,
>  } sev_ret_code;
>  

  reply	other threads:[~2024-11-05 21:58 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-05  1:05 [PATCH v4 0/6] Support SEV firmware hotloading Dionna Glaze
2024-11-05  1:05 ` [PATCH v4 1/6] kvm: svm: Fix gctx page leak on invalid inputs Dionna Glaze
2024-11-06 14:29   ` Tom Lendacky
2024-11-08  9:08     ` Paolo Bonzini
2024-11-06 14:34   ` Sean Christopherson
2024-11-06 15:30     ` Dionna Amalie Glaze
2024-11-06 15:47       ` Sean Christopherson
2024-11-05  1:05 ` [PATCH v4 2/6] firmware_loader: Move module refcounts to allow unloading Dionna Glaze
2024-11-05  1:05 ` [PATCH v4 3/6] crypto: ccp: Track GCTX through sev commands Dionna Glaze
2024-11-05 12:08   ` kernel test robot
2024-11-05 21:06   ` Tom Lendacky
2024-11-05  1:05 ` [PATCH v4 4/6] crypto: ccp: Add DOWNLOAD_FIRMWARE_EX support Dionna Glaze
2024-11-05 21:58   ` Tom Lendacky [this message]
2024-11-05  1:05 ` [PATCH v4 5/6] crypto: ccp: Use firmware_upload API for SNP firmware Dionna Glaze
2024-11-05 22:47   ` Tom Lendacky
2024-11-05  1:05 ` [PATCH v4 6/6] KVM: SVM: Delay legacy platform initialization on SNP Dionna Glaze
2024-11-06 14:45   ` Tom Lendacky

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=f6810eb0-3834-e5b4-6c1f-9422dfff5560@amd.com \
    --to=thomas.lendacky@amd.com \
    --cc=ashish.kalra@amd.com \
    --cc=bp@alien8.de \
    --cc=davem@davemloft.net \
    --cc=dionnaglaze@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=john.allen@amd.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.roth@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

all inboxes | Powered by JetHome®