diff mbox series

crypto: ccp - Retry SEV INIT command in case of integrity check failure.

Message ID 20191017223459.64281-1-Ashish.Kalra@amd.com (mailing list archive)
State New, archived
Headers show
Series crypto: ccp - Retry SEV INIT command in case of integrity check failure. | expand

Commit Message

Kalra, Ashish Oct. 17, 2019, 10:35 p.m. UTC
From: Ashish Kalra <ashish.kalra@amd.com>

SEV INIT command loads the SEV related persistent data from NVS
and initializes the platform context. The firmware validates the
persistent state. If validation fails, the firmware will reset
the persisent state and return an integrity check failure status.

At this point, a subsequent INIT command should succeed, so retry
the command. The INIT command retry is only done during driver
initialization.

Additional enums along with SEV_RET_SECURE_DATA_INVALID are added
to sev_ret_code to maintain continuity and relevance of enum values.

Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
---
 drivers/crypto/ccp/psp-dev.c | 12 ++++++++++++
 include/uapi/linux/psp-sev.h |  3 +++
 2 files changed, 15 insertions(+)

Comments

David Rientjes Oct. 19, 2019, 8:59 a.m. UTC | #1
On Thu, 17 Oct 2019, Kalra, Ashish wrote:

> From: Ashish Kalra <ashish.kalra@amd.com>
> 
> SEV INIT command loads the SEV related persistent data from NVS
> and initializes the platform context. The firmware validates the
> persistent state. If validation fails, the firmware will reset
> the persisent state and return an integrity check failure status.
> 
> At this point, a subsequent INIT command should succeed, so retry
> the command. The INIT command retry is only done during driver
> initialization.
> 
> Additional enums along with SEV_RET_SECURE_DATA_INVALID are added
> to sev_ret_code to maintain continuity and relevance of enum values.
> 
> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
> ---
>  drivers/crypto/ccp/psp-dev.c | 12 ++++++++++++
>  include/uapi/linux/psp-sev.h |  3 +++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> index 6b17d179ef8a..f9318d4482f2 100644
> --- a/drivers/crypto/ccp/psp-dev.c
> +++ b/drivers/crypto/ccp/psp-dev.c
> @@ -1064,6 +1064,18 @@ void psp_pci_init(void)
>  
>  	/* Initialize the platform */
>  	rc = sev_platform_init(&error);
> +	if (rc && (error == SEV_RET_SECURE_DATA_INVALID)) {
> +		/*
> +		 * INIT command returned an integrity check failure
> +		 * status code, meaning that firmware load and
> +		 * validation of SEV related persistent data has
> +		 * failed and persistent state has been erased.
> +		 * Retrying INIT command here should succeed.
> +		 */
> +		dev_dbg(sp->dev, "SEV: retrying INIT command");
> +		rc = sev_platform_init(&error);
> +	}
> +
>  	if (rc) {
>  		dev_err(sp->dev, "SEV: failed to INIT error %#x\n", error);
>  		return;

Curious why this isn't done in __sev_platform_init_locked() since 
sev_platform_init() can be called when loading the kvm module and the same 
init failure can happen that way.

> diff --git a/include/uapi/linux/psp-sev.h b/include/uapi/linux/psp-sev.h
> index 8654b2442f6a..a8537f4e5e08 100644
> --- a/include/uapi/linux/psp-sev.h
> +++ b/include/uapi/linux/psp-sev.h
> @@ -58,6 +58,9 @@ typedef enum {
>  	SEV_RET_HWSEV_RET_PLATFORM,
>  	SEV_RET_HWSEV_RET_UNSAFE,
>  	SEV_RET_UNSUPPORTED,
> +	SEV_RET_INVALID_PARAM,
> +	SEV_RET_RESOURCE_LIMIT,
> +	SEV_RET_SECURE_DATA_INVALID,
>  	SEV_RET_MAX,
>  } sev_ret_code;
>
Brijesh Singh Oct. 21, 2019, 6:16 p.m. UTC | #2
On 10/19/19 3:59 AM, David Rientjes wrote:
> On Thu, 17 Oct 2019, Kalra, Ashish wrote:
> 
>> From: Ashish Kalra <ashish.kalra@amd.com>
>>
>> SEV INIT command loads the SEV related persistent data from NVS
>> and initializes the platform context. The firmware validates the
>> persistent state. If validation fails, the firmware will reset
>> the persisent state and return an integrity check failure status.
>>
>> At this point, a subsequent INIT command should succeed, so retry
>> the command. The INIT command retry is only done during driver
>> initialization.
>>
>> Additional enums along with SEV_RET_SECURE_DATA_INVALID are added
>> to sev_ret_code to maintain continuity and relevance of enum values.
>>
>> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
>> ---
>>   drivers/crypto/ccp/psp-dev.c | 12 ++++++++++++
>>   include/uapi/linux/psp-sev.h |  3 +++
>>   2 files changed, 15 insertions(+)
>>
>> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
>> index 6b17d179ef8a..f9318d4482f2 100644
>> --- a/drivers/crypto/ccp/psp-dev.c
>> +++ b/drivers/crypto/ccp/psp-dev.c
>> @@ -1064,6 +1064,18 @@ void psp_pci_init(void)
>>   
>>   	/* Initialize the platform */
>>   	rc = sev_platform_init(&error);
>> +	if (rc && (error == SEV_RET_SECURE_DATA_INVALID)) {
>> +		/*
>> +		 * INIT command returned an integrity check failure
>> +		 * status code, meaning that firmware load and
>> +		 * validation of SEV related persistent data has
>> +		 * failed and persistent state has been erased.
>> +		 * Retrying INIT command here should succeed.
>> +		 */
>> +		dev_dbg(sp->dev, "SEV: retrying INIT command");
>> +		rc = sev_platform_init(&error);
>> +	}
>> +
>>   	if (rc) {
>>   		dev_err(sp->dev, "SEV: failed to INIT error %#x\n", error);
>>   		return;
> 
> Curious why this isn't done in __sev_platform_init_locked() since
> sev_platform_init() can be called when loading the kvm module and the same
> init failure can happen that way.
> 

The FW initialization (aka PLATFORM_INIT) is called in the following
code paths:

1. During system boot up

and

2. After the platform reset command is issued

The patch takes care of #1. Based on the spec, platform reset command
should erase the persistent data and the PLATFORM_INIT should *not* fail
with SEV_RET_SECURE_DATA_INVALID error code. So, I am not able to see
any  strong reason to move the retry code in
__sev_platform_init_locked().

thanks
David Rientjes Oct. 22, 2019, 12:57 a.m. UTC | #3
On Mon, 21 Oct 2019, Singh, Brijesh wrote:

> >> From: Ashish Kalra <ashish.kalra@amd.com>
> >>
> >> SEV INIT command loads the SEV related persistent data from NVS
> >> and initializes the platform context. The firmware validates the
> >> persistent state. If validation fails, the firmware will reset
> >> the persisent state and return an integrity check failure status.
> >>
> >> At this point, a subsequent INIT command should succeed, so retry
> >> the command. The INIT command retry is only done during driver
> >> initialization.
> >>
> >> Additional enums along with SEV_RET_SECURE_DATA_INVALID are added
> >> to sev_ret_code to maintain continuity and relevance of enum values.
> >>
> >> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
> >> ---
> >>   drivers/crypto/ccp/psp-dev.c | 12 ++++++++++++
> >>   include/uapi/linux/psp-sev.h |  3 +++
> >>   2 files changed, 15 insertions(+)
> >>
> >> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> >> index 6b17d179ef8a..f9318d4482f2 100644
> >> --- a/drivers/crypto/ccp/psp-dev.c
> >> +++ b/drivers/crypto/ccp/psp-dev.c
> >> @@ -1064,6 +1064,18 @@ void psp_pci_init(void)
> >>   
> >>   	/* Initialize the platform */
> >>   	rc = sev_platform_init(&error);
> >> +	if (rc && (error == SEV_RET_SECURE_DATA_INVALID)) {
> >> +		/*
> >> +		 * INIT command returned an integrity check failure
> >> +		 * status code, meaning that firmware load and
> >> +		 * validation of SEV related persistent data has
> >> +		 * failed and persistent state has been erased.
> >> +		 * Retrying INIT command here should succeed.
> >> +		 */
> >> +		dev_dbg(sp->dev, "SEV: retrying INIT command");
> >> +		rc = sev_platform_init(&error);
> >> +	}
> >> +
> >>   	if (rc) {
> >>   		dev_err(sp->dev, "SEV: failed to INIT error %#x\n", error);
> >>   		return;
> > 
> > Curious why this isn't done in __sev_platform_init_locked() since
> > sev_platform_init() can be called when loading the kvm module and the same
> > init failure can happen that way.
> > 
> 
> The FW initialization (aka PLATFORM_INIT) is called in the following
> code paths:
> 
> 1. During system boot up
> 
> and
> 
> 2. After the platform reset command is issued
> 
> The patch takes care of #1. Based on the spec, platform reset command
> should erase the persistent data and the PLATFORM_INIT should *not* fail
> with SEV_RET_SECURE_DATA_INVALID error code. So, I am not able to see
> any  strong reason to move the retry code in
> __sev_platform_init_locked().
> 

Hmm, is the sev_platform_init() call in sev_guest_init() intended to do 
SEV_CMD_INIT only after platform reset?  I was under the impression it was 
done in case any previous init failed.
Brijesh Singh Oct. 22, 2019, 1:38 p.m. UTC | #4
On 10/21/19 7:57 PM, David Rientjes wrote:
> On Mon, 21 Oct 2019, Singh, Brijesh wrote:
> 
>>>> From: Ashish Kalra <ashish.kalra@amd.com>
>>>>
>>>> SEV INIT command loads the SEV related persistent data from NVS
>>>> and initializes the platform context. The firmware validates the
>>>> persistent state. If validation fails, the firmware will reset
>>>> the persisent state and return an integrity check failure status.
>>>>
>>>> At this point, a subsequent INIT command should succeed, so retry
>>>> the command. The INIT command retry is only done during driver
>>>> initialization.
>>>>
>>>> Additional enums along with SEV_RET_SECURE_DATA_INVALID are added
>>>> to sev_ret_code to maintain continuity and relevance of enum values.
>>>>
>>>> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
>>>> ---
>>>>    drivers/crypto/ccp/psp-dev.c | 12 ++++++++++++
>>>>    include/uapi/linux/psp-sev.h |  3 +++
>>>>    2 files changed, 15 insertions(+)
>>>>
>>>> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
>>>> index 6b17d179ef8a..f9318d4482f2 100644
>>>> --- a/drivers/crypto/ccp/psp-dev.c
>>>> +++ b/drivers/crypto/ccp/psp-dev.c
>>>> @@ -1064,6 +1064,18 @@ void psp_pci_init(void)
>>>>    
>>>>    	/* Initialize the platform */
>>>>    	rc = sev_platform_init(&error);
>>>> +	if (rc && (error == SEV_RET_SECURE_DATA_INVALID)) {
>>>> +		/*
>>>> +		 * INIT command returned an integrity check failure
>>>> +		 * status code, meaning that firmware load and
>>>> +		 * validation of SEV related persistent data has
>>>> +		 * failed and persistent state has been erased.
>>>> +		 * Retrying INIT command here should succeed.
>>>> +		 */
>>>> +		dev_dbg(sp->dev, "SEV: retrying INIT command");
>>>> +		rc = sev_platform_init(&error);
>>>> +	}
>>>> +
>>>>    	if (rc) {
>>>>    		dev_err(sp->dev, "SEV: failed to INIT error %#x\n", error);
>>>>    		return;
>>>
>>> Curious why this isn't done in __sev_platform_init_locked() since
>>> sev_platform_init() can be called when loading the kvm module and the same
>>> init failure can happen that way.
>>>
>>
>> The FW initialization (aka PLATFORM_INIT) is called in the following
>> code paths:
>>
>> 1. During system boot up
>>
>> and
>>
>> 2. After the platform reset command is issued
>>
>> The patch takes care of #1. Based on the spec, platform reset command
>> should erase the persistent data and the PLATFORM_INIT should *not* fail
>> with SEV_RET_SECURE_DATA_INVALID error code. So, I am not able to see
>> any  strong reason to move the retry code in
>> __sev_platform_init_locked().
>>
> 
> Hmm, is the sev_platform_init() call in sev_guest_init() intended to do
> SEV_CMD_INIT only after platform reset?  I was under the impression it was
> done in case any previous init failed.
> 


The PLATFORM_INIT command is allowed only when FW is in UINIT state. On
boot, the FW will be in UNINIT state and similarly after the platform 
reset command the FW goes back to UNINIT state.

The __sev_platform_init_locked() checks the FW state before issuing the
command, if FW is already in INIT state then it returns immediately.

thanks
David Rientjes Oct. 23, 2019, 12:23 a.m. UTC | #5
On Tue, 22 Oct 2019, Singh, Brijesh wrote:

> >>>> From: Ashish Kalra <ashish.kalra@amd.com>
> >>>>
> >>>> SEV INIT command loads the SEV related persistent data from NVS
> >>>> and initializes the platform context. The firmware validates the
> >>>> persistent state. If validation fails, the firmware will reset
> >>>> the persisent state and return an integrity check failure status.
> >>>>
> >>>> At this point, a subsequent INIT command should succeed, so retry
> >>>> the command. The INIT command retry is only done during driver
> >>>> initialization.
> >>>>
> >>>> Additional enums along with SEV_RET_SECURE_DATA_INVALID are added
> >>>> to sev_ret_code to maintain continuity and relevance of enum values.
> >>>>
> >>>> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
> >>>> ---
> >>>>    drivers/crypto/ccp/psp-dev.c | 12 ++++++++++++
> >>>>    include/uapi/linux/psp-sev.h |  3 +++
> >>>>    2 files changed, 15 insertions(+)
> >>>>
> >>>> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
> >>>> index 6b17d179ef8a..f9318d4482f2 100644
> >>>> --- a/drivers/crypto/ccp/psp-dev.c
> >>>> +++ b/drivers/crypto/ccp/psp-dev.c
> >>>> @@ -1064,6 +1064,18 @@ void psp_pci_init(void)
> >>>>    
> >>>>    	/* Initialize the platform */
> >>>>    	rc = sev_platform_init(&error);
> >>>> +	if (rc && (error == SEV_RET_SECURE_DATA_INVALID)) {
> >>>> +		/*
> >>>> +		 * INIT command returned an integrity check failure
> >>>> +		 * status code, meaning that firmware load and
> >>>> +		 * validation of SEV related persistent data has
> >>>> +		 * failed and persistent state has been erased.
> >>>> +		 * Retrying INIT command here should succeed.
> >>>> +		 */
> >>>> +		dev_dbg(sp->dev, "SEV: retrying INIT command");
> >>>> +		rc = sev_platform_init(&error);
> >>>> +	}
> >>>> +
> >>>>    	if (rc) {
> >>>>    		dev_err(sp->dev, "SEV: failed to INIT error %#x\n", error);
> >>>>    		return;
> >>>
> >>> Curious why this isn't done in __sev_platform_init_locked() since
> >>> sev_platform_init() can be called when loading the kvm module and the same
> >>> init failure can happen that way.
> >>>
> >>
> >> The FW initialization (aka PLATFORM_INIT) is called in the following
> >> code paths:
> >>
> >> 1. During system boot up
> >>
> >> and
> >>
> >> 2. After the platform reset command is issued
> >>
> >> The patch takes care of #1. Based on the spec, platform reset command
> >> should erase the persistent data and the PLATFORM_INIT should *not* fail
> >> with SEV_RET_SECURE_DATA_INVALID error code. So, I am not able to see
> >> any  strong reason to move the retry code in
> >> __sev_platform_init_locked().
> >>
> > 
> > Hmm, is the sev_platform_init() call in sev_guest_init() intended to do
> > SEV_CMD_INIT only after platform reset?  I was under the impression it was
> > done in case any previous init failed.
> > 
> 
> 
> The PLATFORM_INIT command is allowed only when FW is in UINIT state. On
> boot, the FW will be in UNINIT state and similarly after the platform 
> reset command the FW goes back to UNINIT state.
> 
> The __sev_platform_init_locked() checks the FW state before issuing the
> command, if FW is already in INIT state then it returns immediately.
> 

Ah, got it, thanks.

Acked-by: David Rientjes <rientjes@google.com>
Brijesh Singh Oct. 23, 2019, 1:36 a.m. UTC | #6
On 10/17/19 3:35 PM, Kalra, Ashish wrote:
> From: Ashish Kalra <ashish.kalra@amd.com>
>
> SEV INIT command loads the SEV related persistent data from NVS
> and initializes the platform context. The firmware validates the
> persistent state. If validation fails, the firmware will reset
> the persisent state and return an integrity check failure status.
>
> At this point, a subsequent INIT command should succeed, so retry
> the command. The INIT command retry is only done during driver
> initialization.
>
> Additional enums along with SEV_RET_SECURE_DATA_INVALID are added
> to sev_ret_code to maintain continuity and relevance of enum values.
>
> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>


Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>

thanks
Herbert Xu Oct. 25, 2019, 3:25 p.m. UTC | #7
On Thu, Oct 17, 2019 at 10:35:11PM +0000, Kalra, Ashish wrote:
> From: Ashish Kalra <ashish.kalra@amd.com>
> 
> SEV INIT command loads the SEV related persistent data from NVS
> and initializes the platform context. The firmware validates the
> persistent state. If validation fails, the firmware will reset
> the persisent state and return an integrity check failure status.
> 
> At this point, a subsequent INIT command should succeed, so retry
> the command. The INIT command retry is only done during driver
> initialization.
> 
> Additional enums along with SEV_RET_SECURE_DATA_INVALID are added
> to sev_ret_code to maintain continuity and relevance of enum values.
> 
> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
> ---
>  drivers/crypto/ccp/psp-dev.c | 12 ++++++++++++
>  include/uapi/linux/psp-sev.h |  3 +++
>  2 files changed, 15 insertions(+)

Patch applied.  Thanks.
diff mbox series

Patch

diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index 6b17d179ef8a..f9318d4482f2 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -1064,6 +1064,18 @@  void psp_pci_init(void)
 
 	/* Initialize the platform */
 	rc = sev_platform_init(&error);
+	if (rc && (error == SEV_RET_SECURE_DATA_INVALID)) {
+		/*
+		 * INIT command returned an integrity check failure
+		 * status code, meaning that firmware load and
+		 * validation of SEV related persistent data has
+		 * failed and persistent state has been erased.
+		 * Retrying INIT command here should succeed.
+		 */
+		dev_dbg(sp->dev, "SEV: retrying INIT command");
+		rc = sev_platform_init(&error);
+	}
+
 	if (rc) {
 		dev_err(sp->dev, "SEV: failed to INIT error %#x\n", error);
 		return;
diff --git a/include/uapi/linux/psp-sev.h b/include/uapi/linux/psp-sev.h
index 8654b2442f6a..a8537f4e5e08 100644
--- a/include/uapi/linux/psp-sev.h
+++ b/include/uapi/linux/psp-sev.h
@@ -58,6 +58,9 @@  typedef enum {
 	SEV_RET_HWSEV_RET_PLATFORM,
 	SEV_RET_HWSEV_RET_UNSAFE,
 	SEV_RET_UNSUPPORTED,
+	SEV_RET_INVALID_PARAM,
+	SEV_RET_RESOURCE_LIMIT,
+	SEV_RET_SECURE_DATA_INVALID,
 	SEV_RET_MAX,
 } sev_ret_code;