Re: [PATCH v1 4/4] crypto/ccp: Do not initialize SNP for ioctl(SNP_CONFIG)

[Tom Lendacky <thomas.lendacky@amd.com>]

On 4/27/26 11:15, Tycho Andersen wrote:
> From: "Tycho Andersen (AMD)" <tycho@kernel.org>
> 
> Sashiko notes:
> 
>> if SEV initialization fails and KVM is actively running normal VMs, could a
>> userspace process trigger this code path via /dev/sev ioctls (e.g.,
>> SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN
>> execution for an active VM trigger a general protection fault and crash the
>> host?
> 
> Refuse to re-try initialization if SNP is not already initialized for
> SNP_CONFIG.
> 
> This is technically an ABI break: before if SNP initialization failed it
> could be transparently retriggered by this ioctl, and if no VMs were
> running, everything worked fine. Hopefully this is enough of a corner case
> that nobody will notice, but someone does, there are a few options:

Isn't this the same with patch #3? Not sure why it is only called out for
this one.

> 
> * do something like symbol_get() for kvm and refuse to initialize if KVM is
>   loaded
> * check each cpu's HSAVE_PA for non-zero data before re-initializing
> * once initialization has failed, continue to refuse to initialize until
>   the ccp module is unloaded
> 
> Fixes: ceac7fb89e8d ("crypto: ccp - Ensure implicit SEV/SNP init and shutdown in ioctls")
> Reported-by: Sashiko
> Assisted-by: Gemini:gemini-3.1-pro-preview
> Link: https://sashiko.dev/#/patchset/20260324161301.1353976-1-tycho%40kernel.org
> Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
> ---
>  drivers/crypto/ccp/sev-dev.c | 33 ++++-----------------------------
>  1 file changed, 4 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
> index e8c3ac6d989a..5b113908a4f9 100644
> --- a/drivers/crypto/ccp/sev-dev.c
> +++ b/drivers/crypto/ccp/sev-dev.c
> @@ -1727,21 +1727,6 @@ static int sev_move_to_init_state(struct sev_issue_cmd *argp, bool *shutdown_req
>  	return 0;
>  }
>  
> -static int snp_move_to_init_state(struct sev_issue_cmd *argp, bool *shutdown_required)
> -{
> -	int error, rc;
> -
> -	rc = __sev_snp_init_locked(&error, 0);
> -	if (rc) {
> -		argp->error = SEV_RET_INVALID_PLATFORM_STATE;
> -		return rc;
> -	}
> -
> -	*shutdown_required = true;
> -
> -	return 0;
> -}
> -
>  static int sev_ioctl_do_reset(struct sev_issue_cmd *argp, bool writable)
>  {
>  	int state, rc;
> @@ -2451,8 +2436,6 @@ static int sev_ioctl_do_snp_set_config(struct sev_issue_cmd *argp, bool writable
>  {
>  	struct sev_device *sev = psp_master->sev_data;
>  	struct sev_user_data_snp_config config;
> -	bool shutdown_required = false;
> -	int ret, error;
>  
>  	if (!argp->data)
>  		return -EINVAL;
> @@ -2460,21 +2443,13 @@ static int sev_ioctl_do_snp_set_config(struct sev_issue_cmd *argp, bool writable
>  	if (!writable)
>  		return -EPERM;
>  
> +	if (!sev->snp_initialized)
> +		return -EINVAL;

Maybe -ENODEV to distinguish this situation?

Thanks,
Tom

> +
>  	if (copy_from_user(&config, (void __user *)argp->data, sizeof(config)))
>  		return -EFAULT;
>  
> -	if (!sev->snp_initialized) {
> -		ret = snp_move_to_init_state(argp, &shutdown_required);
> -		if (ret)
> -			return ret;
> -	}
> -
> -	ret = __sev_do_cmd_locked(SEV_CMD_SNP_CONFIG, &config, &argp->error);
> -
> -	if (shutdown_required)
> -		__sev_snp_shutdown_locked(&error, false);
> -
> -	return ret;
> +	return __sev_do_cmd_locked(SEV_CMD_SNP_CONFIG, &config, &argp->error);
>  }
>  
>  static int sev_ioctl_do_snp_vlek_load(struct sev_issue_cmd *argp, bool writable)