All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.