On Tue, 18 May 2021 18:55:56 +0200 Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote: > 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? 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? for the reboot case, yes, since the mm is not directly affected. for the shutdown case, I'm not sure.
