linux-kernel - Re: [PATCH] crypto: ccp - Retry SEV INIT command in case of integrity check failure.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <29887804-ecab-ae83-8d3f-52ea83e44b4e@amd.com>
Date:   Mon, 21 Oct 2019 18:16:48 +0000
From:   "Singh, Brijesh" <brijesh.singh@....com>
To:     David Rientjes <rientjes@...gle.com>,
        "Kalra, Ashish" <Ashish.Kalra@....com>
CC:     "Singh, Brijesh" <brijesh.singh@....com>,
        "Lendacky, Thomas" <Thomas.Lendacky@....com>,
        "Hook, Gary" <Gary.Hook@....com>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "allison@...utok.net" <allison@...utok.net>,
        "info@...ux.net" <info@...ux.net>,
        "yamada.masahiro@...ionext.com" <yamada.masahiro@...ionext.com>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [PATCH] crypto: ccp - Retry SEV INIT command in case of integrity
 check failure.



On 10/19/19 3:59 AM, David Rientjes wrote:
> On Thu, 17 Oct 2019, Kalra, Ashish wrote:
> 
>> From: Ashish Kalra <ashish.kalra@....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@....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