On 14/04/2022 10.02, Claudio Imbrenda wrote:
With upcoming patches, protected guests will be able to trigger secure storage violations in normal operation. A secure storage violation is triggered when a protected guest tries to access secure memory that has been mapped erroneously, or that belongs to a different protected guest or to the ultravisor. With upcoming patches, protected guests will be able to trigger secure storage violations in normal operation.
You've already used this sentence as 1st sentence of the patch description. Looks weird to read it again. Maybe scratch the 1st sentence?
This happens for example if a protected guest is rebooted with lazy destroy enabled and the new guest is also protected. When the new protected guest touches pages that have not yet been destroyed, and thus are accounted to the previous protected guest, a secure storage violation is raised. This patch adds handling of secure storage violations for protected guests. This exception is handled by first trying to destroy the page, because it is expected to belong to a defunct protected guest where a destroy should be possible. If that fails, a normal export of the page is attempted.
>
Therefore, pages that trigger the exception will be made non-secure before attempting to use them again for a different secure guest.
I'm an complete ignorant here, but isn't this somewhat dangerous? Could it happen that a VM could destroy/export the pages of another secure guest that way?
Thomas
