[libvirt] Matching the type of mediated devices in the migration

[Tian, Kevin]

> From: Wang, Zhi A
> Sent: Wednesday, August 22, 2018 2:43 AM
> >
> > Are there any suggestions how we can deal with security issues?
> > Allowing userspace to provide a data stream representing the internal
> > state of a virtual device model living within the kernel seems
> > troublesome.  If we need to trust the data stream, do we need to
> > somehow make the operation more privileged than what a vfio user
> might
> > have otherwise?  Does the data stream need to be somehow signed and
> how
> > might we do that?  How can we build in protection against an untrusted
> > restore image?  Thanks,

imo it is not necessary. restoring mdev state should be handled as if
guest is programming the mdev. Then all the audits/security checks
enforced in normal emulation path should still apply. vendor driver
may choose to audit every state restore operation one-by-one, and 
do it altoghter at a synchronization point (e.g. when the mdev is re-
scheduled, similar to what we did before VMENTRY).

> What a good point!
> 
> I dig the kernel module security case, which seems similar with this
> case. The security of loading kernel module relies on root privilege and
> signature.
> 
> For root privilege, QEMU could run as non root in libvirtd. So this
> wouldn't be an option.
> 
> For signature, I am wondering if there is any similar cases in other
> kernel components, like KVM or another modules which provides ioctls to
> userspace. Maybe they don't even load some binary from userspace, but
> they could suffer from DDOS flood from userspace. Maybe some ioctls or
> interfaces in kernel should only allow signed/trusted userspace
> application to call. (previously it's "allow signed kernel module to load")
> 
> Thanks,
> Zhi.
> 
> >
> > Alex
> >