> 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 > > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
