Re: [libvirt] [PATCH 8/8] docs: Improve documentation related to memory locking
On Fri, 2017-03-24 at 13:58 -0400, Luiz Capitulino wrote:
[...]
> + be allowed to swap them out, which might be required
for some
> + workloads such as RT. For QEMU/KVM guests, the memory used by the QEMU
Minor, but I'd do s/RT/real-time. As this doc is for the general population,
RT may not be a know term for everyone.
Sure.
> + process itself will be locked too: unlike guest memory,
this is an
> + amount libvirt has no way of figuring out in advance, so it has to
> + remove the limit on locked memory altogether. This can be very
> + dangerous as the host might run out of memory and be unable to reclaim
> + it from the guest,
I'd rewrite this to:
"""
This option has a drawback and a possible security risk for the host. If
the host is running out of memory, it will be unable to reclaim the
memory locked by this guest which could cause the host to run out of
memory. In particular, a malicious guest could be able to lock as much
memory it wants, causing a DDoS attack in the host. For setups where
this may have a significant impact, it is highly recommended to use
<hard_limit> to prevent this attack.
"""
Another stab at it (which plugs into my original version):
[...] remove the limit on locked memory altogether. Thus,
enabling this option opens up to a potential security risk:
the host will be unable to reclaim the locked memory back
from the guest when it's running out of memory, which means
a malicious guest allocating large amounts of locked memory
could cause a denial-of-service attach on the host. Because
of this, using the option is discouraged unless your [...]
Does it look reasonable?
--
Andrea Bolognani / Red Hat / Virtualization