mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Kalra, Ashish" <ashish.kalra@amd.com>
To: Dionna Amalie Glaze <dionnaglaze@google.com>
Cc: seanjc@google.com, pbonzini@redhat.com, tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
	x86@kernel.org, hpa@zytor.com, thomas.lendacky@amd.com,
	john.allen@amd.com, herbert@gondor.apana.org.au,
	michael.roth@amd.com, nikunj@amd.com, ardb@kernel.org,
	kevinloughlin@google.com, Neeraj.Upadhyay@amd.com, aik@amd.com,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-crypto@vger.kernel.org, linux-coco@lists.linux.dev
Subject: Re: [PATCH v4 2/7] crypto: ccp: Ensure implicit SEV/SNP init and shutdown in ioctls
Date: Thu, 20 Feb 2025 16:18:22 -0600	[thread overview]
Message-ID: <f227fa9a-f609-41f3-a63b-1c37ded33134@amd.com> (raw)
In-Reply-To: <CAAH4kHYXGNTFABo7hWCQvvebiv4VkXfT8HvV-FPneyQcrHA-9w@mail.gmail.com>

On 2/20/2025 3:37 PM, Dionna Amalie Glaze wrote:
> On Thu, Feb 20, 2025 at 12:07 PM Kalra, Ashish <ashish.kalra@amd.com> wrote:
>>
>> Hello Dionna,
>>
>> On 2/20/2025 10:44 AM, Dionna Amalie Glaze wrote:
>>> On Wed, Feb 19, 2025 at 12:53 PM Ashish Kalra <Ashish.Kalra@amd.com> wrote:
>>>>
>>>> From: Ashish Kalra <ashish.kalra@amd.com>
>>>>
>>>> Modify the behavior of implicit SEV initialization in some of the
>>>> SEV ioctls to do both SEV initialization and shutdown and add
>>>> implicit SNP initialization and shutdown to some of the SNP ioctls
>>>> so that the change of SEV/SNP platform initialization not being
>>>> done during PSP driver probe time does not break userspace tools
>>>> such as sevtool, etc.
>>>>
>>>> Prior to this patch, SEV has always been initialized before these
>>>> ioctls as SEV initialization is done as part of PSP module probe,
>>>> but now with SEV initialization being moved to KVM module load instead
>>>> of PSP driver probe, the implied SEV INIT actually makes sense and gets
>>>> used and additionally to maintain SEV platform state consistency
>>>> before and after the ioctl SEV shutdown needs to be done after the
>>>> firmware call.
>>>>
>>>> It is important to do SEV Shutdown here with the SEV/SNP initialization
>>>> moving to KVM, an implicit SEV INIT here as part of the SEV ioctls not
>>>> followed with SEV Shutdown will cause SEV to remain in INIT state and
>>>> then a future SNP INIT in KVM module load will fail.
>>>>
>>>> Similarly, prior to this patch, SNP has always been initialized before
>>>> these ioctls as SNP initialization is done as part of PSP module probe,
>>>> therefore, to keep a consistent behavior, SNP init needs to be done
>>>> here implicitly as part of these ioctls followed with SNP shutdown
>>>> before returning from the ioctl to maintain the consistent platform
>>>> state before and after the ioctl.
>>>>
>>>> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
>>>> ---
>>>>  drivers/crypto/ccp/sev-dev.c | 117 ++++++++++++++++++++++++++++-------
>>>>  1 file changed, 93 insertions(+), 24 deletions(-)
>>>>
>>>> diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
>>>> index 8f5c474b9d1c..b06f43eb18f7 100644
>>>> --- a/drivers/crypto/ccp/sev-dev.c
>>>> +++ b/drivers/crypto/ccp/sev-dev.c
>>>> @@ -1461,7 +1461,8 @@ static int sev_ioctl_do_platform_status(struct sev_issue_cmd *argp)
>>>>  static int sev_ioctl_do_pek_pdh_gen(int cmd, struct sev_issue_cmd *argp, bool writable)
>>>>  {
>>>>         struct sev_device *sev = psp_master->sev_data;
>>>> -       int rc;
>>>> +       bool shutdown_required = false;
>>>> +       int rc, error;
>>>>
>>>>         if (!writable)
>>>>                 return -EPERM;
>>>> @@ -1470,19 +1471,26 @@ static int sev_ioctl_do_pek_pdh_gen(int cmd, struct sev_issue_cmd *argp, bool wr
>>>>                 rc = __sev_platform_init_locked(&argp->error);
>>>>                 if (rc)
>>>>                         return rc;
>>>> +               shutdown_required = true;
>>>>         }
>>>>
>>>> -       return __sev_do_cmd_locked(cmd, NULL, &argp->error);
>>>> +       rc = __sev_do_cmd_locked(cmd, NULL, &argp->error);
>>>> +
>>>> +       if (shutdown_required)
>>>> +               __sev_platform_shutdown_locked(&error);
>>>
>>> This error is discarded. Is that by design? If so, It'd be better to
>>> call this ignored_error.
>>>
>>
>> This is by design, we cannot overwrite the error for the original command being issued
>> here which in this case is do_pek_pdh_gen, hence we use a local error for the shutdown command.
>> And __sev_platform_shutdown_locked() has it's own error logging code, so it will be printing
>> the error message for the shutdown command failure, so the shutdown error is not eventually
>> being ignored, that error log will assist in any inconsistent SEV/SNP platform state and
>> subsequent errors.
>>
>>>> +
>>>> +       return rc;
>>>>  }
>>>>
>>>>  static int sev_ioctl_do_pek_csr(struct sev_issue_cmd *argp, bool writable)
>>>>  {
>>>>         struct sev_device *sev = psp_master->sev_data;
>>>>         struct sev_user_data_pek_csr input;
>>>> +       bool shutdown_required = false;
>>>>         struct sev_data_pek_csr data;
>>>>         void __user *input_address;
>>>>         void *blob = NULL;
>>>> -       int ret;
>>>> +       int ret, error;
>>>>
>>>>         if (!writable)
>>>>                 return -EPERM;
>>>> @@ -1513,6 +1521,7 @@ static int sev_ioctl_do_pek_csr(struct sev_issue_cmd *argp, bool writable)
>>>>                 ret = __sev_platform_init_locked(&argp->error);
>>>>                 if (ret)
>>>>                         goto e_free_blob;
>>>> +               shutdown_required = true;
>>>>         }
>>>>
>>>>         ret = __sev_do_cmd_locked(SEV_CMD_PEK_CSR, &data, &argp->error);
>>>> @@ -1531,6 +1540,9 @@ static int sev_ioctl_do_pek_csr(struct sev_issue_cmd *argp, bool writable)
>>>>         }
>>>>
>>>>  e_free_blob:
>>>> +       if (shutdown_required)
>>>> +               __sev_platform_shutdown_locked(&error);
>>>
>>> Another discarded error. This function is called in different
>>> locations in sev-dev.c with and without checking the result, which
>>> seems problematic.
>>
>> Not really, if shutdown fails for any reason, the error is printed.
>> The return value here reflects the value of the original command/function.
>> The command/ioctl could have succeeded but the shutdown failed, hence,
>> shutdown error is printed, but the return value reflects that the ioctl succeeded.
>>
>> Additionally, in case of INIT before the command is issued, the command may
>> have failed without the SEV state being in INIT state, hence the error for the
>> INIT command failure is returned back from the ioctl.
>>
>>>
>>>> +
>>>>         kfree(blob);
>>>>         return ret;
>>>>  }
>>>> @@ -1747,8 +1759,9 @@ static int sev_ioctl_do_pek_import(struct sev_issue_cmd *argp, bool writable)
>>>>         struct sev_device *sev = psp_master->sev_data;
>>>>         struct sev_user_data_pek_cert_import input;
>>>>         struct sev_data_pek_cert_import data;
>>>> +       bool shutdown_required = false;
>>>>         void *pek_blob, *oca_blob;
>>>> -       int ret;
>>>> +       int ret, error;
>>>>
>>>>         if (!writable)
>>>>                 return -EPERM;
>>>> @@ -1780,11 +1793,15 @@ static int sev_ioctl_do_pek_import(struct sev_issue_cmd *argp, bool writable)
>>>>                 ret = __sev_platform_init_locked(&argp->error);
>>>>                 if (ret)
>>>>                         goto e_free_oca;
>>>> +               shutdown_required = true;
>>>>         }
>>>>
>>>>         ret = __sev_do_cmd_locked(SEV_CMD_PEK_CERT_IMPORT, &data, &argp->error);
>>>>
>>>>  e_free_oca:
>>>> +       if (shutdown_required)
>>>> +               __sev_platform_shutdown_locked(&error);
>>>
>>> Again.
>>>
>>>> +
>>>>         kfree(oca_blob);
>>>>  e_free_pek:
>>>>         kfree(pek_blob);
>>>> @@ -1901,17 +1918,8 @@ static int sev_ioctl_do_pdh_export(struct sev_issue_cmd *argp, bool writable)
>>>>         struct sev_data_pdh_cert_export data;
>>>>         void __user *input_cert_chain_address;
>>>>         void __user *input_pdh_cert_address;
>>>> -       int ret;
>>>> -
>>>> -       /* If platform is not in INIT state then transition it to INIT. */
>>>> -       if (sev->state != SEV_STATE_INIT) {
>>>> -               if (!writable)
>>>> -                       return -EPERM;
>>>> -
>>>> -               ret = __sev_platform_init_locked(&argp->error);
>>>> -               if (ret)
>>>> -                       return ret;
>>>> -       }
>>>> +       bool shutdown_required = false;
>>>> +       int ret, error;
>>>>
>>>>         if (copy_from_user(&input, (void __user *)argp->data, sizeof(input)))
>>>>                 return -EFAULT;
>>>> @@ -1952,6 +1960,16 @@ static int sev_ioctl_do_pdh_export(struct sev_issue_cmd *argp, bool writable)
>>>>         data.cert_chain_len = input.cert_chain_len;
>>>>
>>>>  cmd:
>>>> +       /* If platform is not in INIT state then transition it to INIT. */
>>>> +       if (sev->state != SEV_STATE_INIT) {
>>>> +               if (!writable)
>>>> +                       goto e_free_cert;
>>>> +               ret = __sev_platform_init_locked(&argp->error);
>>>
>>> Using argp->error for init instead of the ioctl-requested command
>>> means that the user will have difficulty distinguishing which process
>>> is at fault, no?
>>>
>>
>> Not really, in case the SEV command has still not been issued, argp->error is still usable
>> and returned back to the caller (no need to use a local error here), we are not overwriting
>> the argp->error used for the original command/ioctl here.
>>
> 
> I mean in the case that argp->error is set to a value shared by the
> command and init, it's hard to know what the problem was.
> I'd like to ensure that the documentation is updated to reflect that
> (in this case) if PDH_CERT_EXPORT returns INVALID_PLATFORM_STATE, then
> it's because the platform was not in PSTATE.UNINIT state.
> The new behavior of initializing when you need to now means that you
> should have ruled out INVALID_PLATFORM_STATE as a possible value from
> PDH_EXPORT_CERT. Same for SNP_CONFIG.
> 
> There is not a 1-to-1 mapping between the ioctl commands and the SEV
> commands now, so I think you need extra documentation to clarify the
> new error space for at least pdh_export and set_config
> 
> SNP_PLATFORM_STATUS, VLEK_LOAD, and SNP_COMMIT appear to not
> necessarily have a provenance confusion after looking closer.
> 
> 

I am more of less trying to match the current behavior of sev_ioctl_do_pek_import()
or sev_ioctl_do_pdh_export().

All this is implementation specific handling so we can't update SEV/SNP firmware
API specs documentation for this new error space, this is not a firmware specific return code. 

But to maintain 1-to-1 mapping between the ioctl commands and the SEV/SNP commands, 
i think it will be better to handle this INIT in the same way as SHUTDOWN, which
is to use a local error for INIT and in case of implicit INIT failures, let the
error logs from __sev_platform_init_locked() OR __sev_snp_init_locked() be printed
and always return INVALID_PLATFORM_STATE as error back to the caller.

Thanks,
Ashish


  reply	other threads:[~2025-02-20 22:18 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-19 20:52 [PATCH v4 0/7] Move initializing SEV/SNP functionality to KVM Ashish Kalra
2025-02-19 20:52 ` [PATCH v4 1/7] crypto: ccp: Move dev_info/err messages for SEV/SNP init and shutdown Ashish Kalra
2025-02-20 18:27   ` Tom Lendacky
2025-02-19 20:53 ` [PATCH v4 2/7] crypto: ccp: Ensure implicit SEV/SNP init and shutdown in ioctls Ashish Kalra
2025-02-20 16:44   ` Dionna Amalie Glaze
2025-02-20 20:07     ` Kalra, Ashish
2025-02-20 21:37       ` Dionna Amalie Glaze
2025-02-20 22:18         ` Kalra, Ashish [this message]
2025-02-20 22:39           ` Dionna Amalie Glaze
2025-02-19 20:53 ` [PATCH v4 3/7] crypto: ccp: Reset TMR size at SNP Shutdown Ashish Kalra
2025-02-20 16:47   ` Dionna Amalie Glaze
2025-02-20 18:55   ` Tom Lendacky
2025-02-19 20:53 ` [PATCH v4 4/7] crypto: ccp: Register SNP panic notifier only if SNP is enabled Ashish Kalra
2025-02-20 19:08   ` Tom Lendacky
2025-02-19 20:54 ` [PATCH v4 5/7] crypto: ccp: Add new SEV/SNP platform shutdown API Ashish Kalra
2025-02-20 19:21   ` Tom Lendacky
2025-02-19 20:54 ` [PATCH v4 6/7] KVM: SVM: Add support to initialize SEV/SNP functionality in KVM Ashish Kalra
2025-02-20 19:57   ` Tom Lendacky
2025-02-19 20:55 ` [PATCH v4 7/7] crypto: ccp: Move SEV/SNP Platform initialization to KVM Ashish Kalra
2025-02-20 20:03   ` Tom Lendacky
2025-02-20 20:23     ` Kalra, Ashish
2025-02-20 21:05       ` 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=f227fa9a-f609-41f3-a63b-1c37ded33134@amd.com \
    --to=ashish.kalra@amd.com \
    --cc=Neeraj.Upadhyay@amd.com \
    --cc=aik@amd.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dionnaglaze@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=hpa@zytor.com \
    --cc=john.allen@amd.com \
    --cc=kevinloughlin@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.roth@amd.com \
    --cc=mingo@redhat.com \
    --cc=nikunj@amd.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.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

all inboxes | Powered by JetHome®