On Mon, 2021-03-08 at 15:57 +0000, Daniel P. Berrangé wrote: > On Mon, Mar 08, 2021 at 04:32:26PM +0100, Andrea Bolognani wrote: > > On Mon, 2021-03-08 at 13:17 +0000, Daniel P. Berrangé wrote: > > > Since you added code to parse existing limits from /proc, I'm wondering > > > if we can just do without the config option. Simply try to use prlimit > > > and if it fails, query existing limits to determine if we sould treat > > > the prlimit as fatal or ignore it. Overall I'd prefer libvirt to > > > "just work" out of the box rather than requiring people to know about > > > setting a "make-vfio-hotplug-work=yes" flag in the config file. > > > > The problem with that approach is what to do when *lowering* the > > limit, for example as a consequence of hot-unplugging the last VFIO > > device from the VM. > > > > If we're controlling the memory locking limit ourselves, then failure > > to lower it should be an error, because leaving the limit much higher > > than necessary creates potential for DoS by a compromised QEMU; on > > the other hand, if the limit is controlled by an external process, > > all we can really do is assume they will do the right thing after > > hot-unplugging has happened. > > IMHO once QEMU vCPUs start running, immediately assume QEMU is > compromised / hostile. IOW, the DoS risk arrived the moment it > was given the higher limit. We're just failing to close off the > existing risk we've already accepted, which doesn't worry me much. > > On unplug the only thing we actually do when memory lock reduce > fails is to log a warning message, it is never treated as a > fatal error. > > So the only difference is whether we skip the warning message > when we get EPERM from prlimit(), or always emit the warning. You're right, we're currently just soft-failing when we can't lower the memlock limit on unplug. Given this and your assessment of the security implications, which I trust, we should indeed be able to avoid introducing the qemu.conf knob and just behave sanely in all scenarios out of the box. I'll give it a try. -- Andrea Bolognani / Red Hat / Virtualization
