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]

Date:   Fri, 27 Oct 2017 16:28:31 -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 3:27 PM, Borislav Petkov wrote:
> On Fri, Oct 27, 2017 at 03:25:24PM -0500, Brijesh Singh wrote:
>> Yep, we are doing state transition only when we really need to. At least
>> so far I have tried to avoid making any unnecessary state transitions.
> So change all those which do INIT -> CMD -> SHUTDOWN to do only the
> command as the INIT state is the default state, AFAIU it.
>
I don't that will work. It may be possible that I am not able to follow
what exactly you have in mind. Please let me clarify it, on boot the
firmware is in UINIT state.

Firmware maintain three states: UINIT, INIT and WORKING. Few commands
can be executed in UINIT, several command can be executed in INIT, some
command can be executed in WORKING and few commands can be executed in
any states (see SEV spec for platform state). We do not have ioctls to
issue the INIT and SHUTDOWN command.

As I have explained in previous messages, the SHUTDOWN unconditionally
destory's the FW context hence we have refrained from providing the
access for this command to userspace.

My approach is, when userspace issues a command we check if command
requires INIT state, if so then we do INIT -> CMD -> SHUTDOWN. If
command can be executed in any state then we issue the command . If
command need to be executed in UINIT state then we *do not* do
SHUTDOWN->CMD, instead we issue the cmd and PSP will fail with error
code and caller can check the error code to determine why command failed.

If I go with your recommendation then I am not able to see who will
transition the platform from UINIT -> INIT so that command can run?

Lets try with very simple example:

# modprobe ccp

/* FW is in INIT state */

# userspace runs

ioctl(fd, SEV_USER_PEK_GEN, &err)

This will fail because PEK_GEN require the platform in INIT state and
nobody has done the state transition from INIT -> UINIT.

-Brijesh