Re: [libvirt] Matching the type of mediated devices in the migration
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
>