[libvirt] [PATCH 8/8] docs: Improve documentation related to memory locking
Luiz Capitulino
lcapitulino at redhat.com
Tue Mar 28 13:43:02 UTC 2017
On Mon, 27 Mar 2017 12:33:48 +0200
Andrea Bolognani <abologna at redhat.com> wrote:
> 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?
That looks fine, although I'd drop "discouraged" because that's
not helpful to those who must use the feature. I think it's better
to objectively explain what the problems are and how to prevent or
mitigate them. That's what I tried to do in my paragraph.
More information about the libvir-list
mailing list