> > If I understanding correctly then you are recommending that instead of > > exporting various functions from PSP drv we should expose one function > > for the all the guest command handling (something like this). > > > > My understanding is that a user could exhaust the ASIDs for encrypted > > VMs if it was allowed to start an arbitrary number of KVM guests. So > > we would need some kind of control. Is this correct? > > Yes, there is limited number of ASIDs for encrypted VMs. Do we need to > pass the psp_fd into SEV_ISSUE_CMD ioctl or can we handle it from Qemu > itself ? e.g when user asks to transition a guest into SEV-enabled mode > then before calling LAUNCH_START Qemu tries to open /dev/psp device. If > open() returns success then we know user has permission to communicate > with PSP firmware.
No, this is a stateful mechanism and it's hard to implement. Passing a /dev/psp file descriptor is the simplest way to "prove" that you have access to the device. Thanks, Paolo > > If so, does /dev/psp provide any functionality that you believe is > > dangerous for the KVM userspace (which runs in a very confined > > environment)? Is this functionality blocked through capability > > checks? > > I do not see /dev/psp providing anything which would be dangerous to KVM > userspace. It should be safe to access /dev/psp into KVM userspace. _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
