Re: [Qemu-devel] [PATCH 1/1] balloon: add a feature bit to let Guest OS deflate balloon on oom

[Christian Borntraeger <borntraeger@de.ibm.com>]

Am 15.06.2015 um 11:06 schrieb Michael S. Tsirkin:

>>> AFAIK management tools depend on balloon not deflating
>>> below host-specified threshold to avoid OOM on the host.
>>> So I don't think we can make this a default,
>>> management needs to enable this explicitly.
>>
>> If the ballooning is required to keep the host memory managedment
>> from OOM - iow abusing ballooning as memory hotplug between guests
>> then yes better let the guest oom - that makes sense.
>>
>> Now: I think that doing so (not having enough swap in the host if
>> all guests deflate) and relying on balloon semantics is fundamentally
>> broken. Let me explain this: The problem is that we rely on guest
>> cooperation for the host integrity. As I explained  using madvise 
>> WONT_NEED will replace the current PTEs with invalid/emtpy PTEs. As
>> soon as the guest kernel re-touches the page (e.g. a malicious 
>> kernel module - not the balloon driver) it will be backed by the VMAs
>> default method - so usually with a shared R/O copy of the empty
>> zero page. Write accesses will result in a copy-on-write and allocate
>> new memory in the host. 
>> There is nothing we can do in the balloon protocol to protect the host
>> against malicious guests allocating all the maximum memory.
> 
> If we want to try and harden host, we can unmap it so guest will crash
> if it touches pages without deflate.
> 
>> If you need host integrity against guest memory usage, something like
>> cgroups_memory or so is probably the only reliable way.
> 
> In the original design, protection against a malicious guest is not the
> point of the balloon, it's a technology that let you overcommit
> cooperative guests.

Sure. But then its perfectly fine to let the guest reclaim by default,
because your statement 
"AFAIK management tools depend on balloon not deflating
 below host-specified threshold to avoid OOM on the host.
 So I don't think we can make this a default,
 management needs to enable this explicitly."

is not true ;-)

Christian