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: <a7b8859b-6537-5ce0-b0d8-bd5932c64251@amd.com>
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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ