[PATCH RFC v2 00/13] IOMMUFD Generic interface

[Daniel P. Berrangé]

On Wed, Sep 21, 2022 at 03:44:24PM -0300, Jason Gunthorpe wrote:
> On Wed, Sep 21, 2022 at 12:06:49PM -0600, Alex Williamson wrote:
> > The issue is where we account these pinned pages, where accounting is
> > necessary such that a user cannot lock an arbitrary number of pages
> > into RAM to generate a DoS attack.  
> 
> It is worth pointing out that preventing a DOS attack doesn't actually
> work because a *task* limit is trivially bypassed by just spawning
> more tasks. So, as a security feature, this is already very
> questionable.

The malicious party on host VM hosts is generally the QEMU process.
QEMU is normally prevented from spawning more tasks, both by SELinux
controls and be the seccomp sandbox blocking clone() (except for
thread creation).  We need to constrain what any individual QEMU can
do to the host, and the per-task mem locking limits can do that.

The mgmt app is what spawns more tasks (QEMU instances) and they
are generally a trusted party on the host, or they are already
constrained in other ways such as cgroups or namespaces. The
mgmt apps would be expected to not intentionally overcommit the
host with VMs needing too much cummulative locked RAM.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|