[libvirt] [PATCH 8/8] docs: Improve documentation related to memory locking

[Andrea Bolognani]

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