public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Singh, Brijesh" <brijesh.singh@amd.com>
To: David Rientjes <rientjes@google.com>,
	"Kalra, Ashish" <Ashish.Kalra@amd.com>
Cc: "Singh, Brijesh" <brijesh.singh@amd.com>,
	"Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
	"Hook, Gary" <Gary.Hook@amd.com>,
	"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"allison@lohutok.net" <allison@lohutok.net>,
	"info@metux.net" <info@metux.net>,
	"yamada.masahiro@socionext.com" <yamada.masahiro@socionext.com>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH] crypto: ccp - Retry SEV INIT command in case of integrity check failure.
Date: Mon, 21 Oct 2019 18:16:48 +0000	[thread overview]
Message-ID: <29887804-ecab-ae83-8d3f-52ea83e44b4e@amd.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1910190156210.140416@chino.kir.corp.google.com>



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

  reply	other threads:[~2019-10-21 18:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-17 22:35 [PATCH] crypto: ccp - Retry SEV INIT command in case of integrity check failure Kalra, Ashish
2019-10-19  8:59 ` David Rientjes
2019-10-21 18:16   ` Singh, Brijesh [this message]
2019-10-22  0:57     ` David Rientjes
2019-10-22 13:38       ` Singh, Brijesh
2019-10-23  0:23         ` David Rientjes
2019-10-23  1:36 ` Singh, Brijesh
2019-10-25 15:25 ` Herbert Xu

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=29887804-ecab-ae83-8d3f-52ea83e44b4e@amd.com \
    --to=brijesh.singh@amd.com \
    --cc=Ashish.Kalra@amd.com \
    --cc=Gary.Hook@amd.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=allison@lohutok.net \
    --cc=davem@davemloft.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=info@metux.net \
    --cc=kvm@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rientjes@google.com \
    --cc=tglx@linutronix.de \
    --cc=yamada.masahiro@socionext.com \
    /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