<div dir="ltr">On 17 January 2014 09:12, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> The physical function is the one with the "real" PCI config space, so as<br>
> long as the host controls it then there should be minimal risk from the<br>
> guests since they have limited access via the virtual functions--typically<br>
> mostly just message-passing to the physical function.<br>
<br>
</div>As long as its a whitelist of audited message handlers, thats fine. Of<br>
course, if the message handlers haven't been audited, who knows whats<br>
lurking in there.</blockquote><div><br></div><div>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.  <br>

<br>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.<br>

-- <br></div><div>Ian.<br></div></div></div></div>