Re: [libvirt] Matching the type of mediated devices in the migration
On Wed, 22 Aug 2018 01:27:05 +0000
"Tian, Kevin" <kevin.tian(a)intel.com> wrote:
> 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.
To me this suggests that a state save/restore is just an algorithm
executed by userspace using the existing vfio device accesses. This is
not at all what we've been discussing for migration. I believe the
interface we've been hashing out exposes opaque device state through a
vfio region. We therefore must assume that that opaque data contains
not only device state, but also emulation state, similar to what we see
for any QEMU device. Not only is there internal emulation state, but
we have no guarantee that the device state goes through the same
auditing as it does through the vfio interface. Since this device and
emulation state live inside the kernel and not just within the user's
own process, a malicious user can do far more than shoot themselves. It
would be one thing devices were IOMMU isolated, but they're not,
they're isolated through vendor and device specific mechanism, and for
all we know the parameters of that isolation are included in the
restore state. I don't see how we can say this is not an issue.
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).
Giving the vendor driver the choice of whether to be secure or not is
exactly what I'm trying to propose we spend some time thinking about.
For instance, what if instead of allowing the user to load device state
through a region, the kernel could side load it using sometime similar
to the firmware loading path. The user could be provided with a file
name token that they push through the vfio interface to trigger the
state loading from a location with proper file level ACLs such that the
image can be considered trusted. Unfortunately the collateral is that
libvirt would need to become the secure delivery entity, somehow
stripping this section of the migration stream into a file and
providing a token for the user to ask the kernel to load it. What are
some other options? Could save/restore be done simply as an
algorithmic script matched to stack of data, as I read into your first
statement above? I have doubts that we can achieve the internal state
we need, or maybe even the performance we need using such a process.
Thanks,
Alex