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 06:28:38 -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 2:56 AM, Borislav Petkov wrote:
> On Thu, Oct 26, 2017 at 03:59:32PM -0500, Brijesh Singh wrote:
>> we can workaround #1 by adding some hooks in sp_pci_init() to invoke the PSP
>> initialization routines after pci_register_driver() is done but #2 can get
>> painful because it will require us calling the SHUTDOWN outside the
>> sp_pci_exit() code flow.
> Ok, do that and init the PSP master and then put the device in UNINIT
> state only in the functions which execute those commands which need the
> device to be in UNINIT state, e.g., wrap the SEV_CMD_FACTORY_RESET glue
> in a command function which does put the device in the UNINIT state as a
> first step.

transiting a platform in UINIT state to handle the FACTORY_RESET can
have a negative consequence.

Consider this scenario:

Process A
---------
sev_launch_start(...)

while (count < 10000) {
    sev_launch_update(...)
}

sev_launch_finish()
...
...

Process B:
---------
....
sev_factory_reset();
....

If in order to handle the FACTORY_RESET we  transition a platform in
UINIT state then it will results as unexpected failure from the
sev_launch_update() because the FACTORY_RESET command remove all the
state information created by sev_launch_start() etc. 

I think our design so far is simple, if command require INIT state then
caller executes sev_platform_init(), then command and finish with
sev_platform_shutdown(). If command does not require INIT state, then
simply issue the command. e.g currently, when caller issues
FACTORY_RESET then we pass command directly to PSP and if FW is in INIT
state then FACTORY_RESET returns error (INVALID_STATE/EBUSY) and we
propagate the error code to userspace.  User can retry the command
sometime later when nobody else is using the PSP.


>
> Then, when that function is done, put the device in the mode which the
> other commands would expect it to be in, e.g., INIT state.
>
> This way you'll simplify the whole command flow considerably and won't
> have to "toggle" the device each time and will save yourself a lot of
> time on command execution.
>
> Thx.
>

Powered by blists - more mailing lists