On Thu, 5 May 2022 19:10:39 +0200 Thomas Huth <thuth@xxxxxxxxxx> wrote: > 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? oops! > > > 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? this is a good question, perhaps I should add a comment explaining that the destroy page UVC will only work on protected VMs with no CPUs. Exporting instead is not an issue, if/when the page is needed, it will get imported again. Unless some things went really wrong, but that can only happen in case of a bug in the hypervisor. > > Thomas >
