| 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 |
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; >
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
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.
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
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>
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
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 --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;