linux-kernel - Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

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: <746a1ce4-f137-5e4a-d768-34aa88893955@amd.com>
Date:   Fri, 27 Oct 2017 17:59:23 -0500
From:   Brijesh Singh <brijesh.singh@....com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     brijesh.singh@....com, kvm@...r.kernel.org,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Gary Hook <gary.hook@....com>,
        Tom Lendacky <thomas.lendacky@....com>,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [Part2 PATCH v6 13/38] crypto: ccp: Add Secure Encrypted
 Virtualization (SEV) command support

On 10/27/17 4:49 PM, Borislav Petkov wrote:
> On Fri, Oct 27, 2017 at 04:28:31PM -0500, Brijesh Singh wrote:
>> This will fail because PEK_GEN require the platform in INIT state and
>> nobody has done the state transition from INIT -> UINIT.
> Huh, FW is in INIT state and PEK_GEN wants it to be in INIT state. Typo?

Yes it is typo. PEK_GEN wants FW to be in INIT state hence someone need
to transition from UNINIT -> INIT.

> Aaanyway, I don't like this whole notion of prematurely and predictively
> executing commands on the PSP if it is not needed. So how about
> executing only those commands which put the FW in the required state and
> then executing the actual command?

That's what I am doing except FACTORY_RESET. The FACTORY_RESET require
the FW to be in UNINIT state,  since we don't who else is running in
parallel hence its not safe to issue the SHUTDOWN to transition from
INIT -> UNINIT. If FW is not in correct state this  command will fail
with error code (INVALID_STATE) and user can retry (please note that
user can always use PLATFORM_STATUS to query the current FW state before
issuing a command). I see that we can do a small optimization -- since
we already know the FW state hence we can avoid issuing PSP command when
we know for sure that command will fail because we are not in correct state.

>
> I.e., if a command needs to be executed in UINIT state, you put the PSP
> in that state before executing that command. If the command needs to be
> in INIT state, you put the PSP in INIT state first and so on...

If command needs INIT state and FW is not in INIT state then its safe to
transition from UNINIT -> INIT. But if command needs UNINIT state and FW
is in INIT state then its not safe to transition -- in those case we
simply return EBUSY and let the user retry the command.