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