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