Open Stack

On 17 January 2014 09:12, Robert Collins <robertc at robertcollins.net> wrote:

> > The physical function is the one with the "real" PCI config space, so as
> > long as the host controls it then there should be minimal risk from the
> > guests since they have limited access via the virtual
> functions--typically
> > mostly just message-passing to the physical function.
>
> As long as its a whitelist of audited message handlers, thats fine. Of
> course, if the message handlers haven't been audited, who knows whats
> lurking in there.


The description doesn't quite gel with my understanding - SRIOV VFs *do*
have a PCI space that you can map in, and a DMA as well, typically (which
is virtualised via the page table for the VM).  However, some functions of
the card may not be controllable in that space (e.g., for network devices,
VLAN encapsulation, promiscuity, and so on) and you may have to make a
request from the VF in the VM to the PF in the host kernel.

The message channels in question are implemented in the PF and VF drivers
in the Linux kernel code (the PF end being the one where security matters,
since a sufficiently malicious VM can try it on at the VF end and see what
happens).  I don't know whether you consider that audited enough.
-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140117/324e074c/attachment.html>