On 18.05.21 18:31, Claudio Imbrenda wrote:
On Tue, 18 May 2021 18:22:42 +0200
David Hildenbrand <david@xxxxxxxxxx> wrote:
On 18.05.21 18:19, Claudio Imbrenda wrote:
On Tue, 18 May 2021 18:04:11 +0200
Cornelia Huck <cohuck@xxxxxxxxxx> wrote:
On Tue, 18 May 2021 17:36:24 +0200
Claudio Imbrenda <imbrenda@xxxxxxxxxxxxx> wrote:
On Tue, 18 May 2021 17:05:37 +0200
Cornelia Huck <cohuck@xxxxxxxxxx> wrote:
On Mon, 17 May 2021 22:07:47 +0200
Claudio Imbrenda <imbrenda@xxxxxxxxxxxxx> wrote:
This means that the same address space can have memory
belonging to more than one protected guest, although only one
will be running, the others will in fact not even have any
CPUs.
Are those set-aside-but-not-yet-cleaned-up pages still possibly
accessible in any way? I would assume that they only belong to
the
in case of reboot: yes, they are still in the address space of the
guest, and can be swapped if needed
'zombie' guests, and any new or rebooted guest is a new entity
that needs to get new pages?
the rebooted guest (normal or secure) will re-use the same pages
of the old guest (before or after cleanup, which is the reason of
patches 3 and 4)
Took a look at those patches, makes sense.
the KVM guest is not affected in case of reboot, so the userspace
address space is not touched.
'guest' is a bit ambiguous here -- do you mean the vm here, and the
actual guest above?
yes this is tricky, because there is the guest OS, which terminates
or reboots, then there is the "secure configuration" entity,
handled by the Ultravisor, and then the KVM VM
when a secure guest reboots, the "secure configuration" is
dismantled (in this case, in a deferred way), and the KVM VM (and
its memory) is not directly affected
what happened before was that the secure configuration was
dismantled synchronously, and then re-created.
now instead, a new secure configuration is created using the same
KVM VM (and thus the same mm), before the old secure configuration
has been completely dismantled. hence the same KVM VM can have
multiple secure configurations associated, sharing the same address
space.
of course, only the newest one is actually running, the other ones
are "zombies", without CPUs.
Can a guest trigger a DoS?
I don't see how
a guest can fill its memory and then reboot, and then fill its memory
again and then reboot... but that will take time, filling the memory
will itself clean up leftover pages from previous boots.
In essence this guest will then synchronously wait for the page to be
exported and reimported, correct?
"normal" reboot loops will be fast, because there won't be much memory
to process
I have actually tested mixed reboot/shutdown loops, and the system
behaved as you would expect when under load.
I guess the memory will continue to be accounted to the memcg? Correct?
