Re: [Qemu-devel] [virtio-dev] Re: Vhost-pci RFC2.0

[Wei Wang]

On 04/19/2017 06:36 PM, Jan Kiszka wrote:
> On 2017-04-19 12:02, Wei Wang wrote:
> > > > > > The design presented here intends to use only one BAR to expose
> > > > > > both TX and RX. The two VMs share an intermediate memory
> > > > > > here, why couldn't we give the same permission to TX and RX?
> > > > > For security and/or safety reasons: the TX side can then safely prepare
> > > > > and sign a message in-place because the RX side cannot mess around with
> > > > > it while not yet being signed (or check-summed). Saves one copy from a
> > > > > secure place into the shared memory.
> > > > If we allow guest1 to write to RX, what safety issue would it cause to
> > > > guest2?
> > > This way, guest1 could trick guest2, in a race condition, to sign a
> > > modified message instead of the original one.
> > Just align the context that we are talking about: RX is the intermediate
> > shared ring that guest1 uses to receive packets and guest2 uses to send
> > packet.
> >
> > Seems the issue is that guest1 will receive a hacked message from RX
> > (modified by itself). How would it affect guest2?
> Retry: guest2 wants to send a signed/hashed message to guest1. For that
> purpose, it starts to build that message inside the shared memory that
> guest1 can at least read, then guest2 signs that message, also in-place.
> If guest1 can modify the message inside the ring while guest2 has not
> yet signed it, the result is invalid.
>
> Now, if guest2 is the final receiver of the message, nothing is lost,
> guest2 just shot itself into the foot. However, if guest2 is just a
> router (gray channel) and the message travels further, guest2 now has
> corrupted that channel without allowing the final receive to detect
> that. That's the scenario.

If guest2 has been a malicious guest, I think it wouldn't make a
difference whether we protect the shared RX or not. As a router,
guest2 can play tricks on the messages after read it and then
send the modified message to a third man, right?


> > > > > > > >      Fig. 4 shows the inter-VM notification path for 2.0 (2.1 is
> > > > > > > > similar).
> > > > > > > > The four eventfds are allocated by virtio-net, and shared with
> > > > > > > > vhost-pci-net:
> > > > > > > > Uses virtio-net’s TX/RX kickfd as the vhost-pci-net’s RX/TX callfd
> > > > > > > > Uses virtio-net’s TX/RX callfd as the vhost-pci-net’s RX/TX kickfd
> > > > > > > > Example of how it works:
> > > > > > > > After packets are put into vhost-pci-net’s TX, the driver kicks TX,
> > > > > > > > which
> > > > > > > > causes the an interrupt associated with fd3 to be injected to
> > > > > > > > virtio-net
> > > > > > > >      The draft code of the 2.0 design is ready, and can be found
> > > > > > > > here:
> > > > > > > > Qemu: _https://github.com/wei-w-wang/vhost-pci-device_
> > > > > > > > Guest driver: _https://github.com/wei-w-wang/vhost-pci-driver_
> > > > > > > >      We tested the 2.0 implementation using the Spirent packet
> > > > > > > > generator to transmit 64B packets, the results show that the
> > > > > > > > throughput of vhost-pci reaches around 1.8Mpps, which is around
> > > > > > > > two times larger than the legacy OVS+DPDK. Also, vhost-pci shows
> > > > > > > > better scalability than OVS+DPDK.
> > > > > > > >      
> > > > > > > Do you have numbers for the symmetric 2.1 case as well? Or is the
> > > > > > > driver
> > > > > > > not yet ready for that yet? Otherwise, I could try to make it work
> > > > > > > over
> > > > > > > a simplistic vhost-pci 2.1 version in Jailhouse as well. That would
> > > > > > > give
> > > > > > > a better picture of how much additional complexity this would mean
> > > > > > > compared to our ivshmem 2.0.
> > > > > > Implementation of 2.1 is not ready yet. We can extend it to 2.1 after
> > > > > > the common driver frame is reviewed.
> > > > > Can you you assess the needed effort?
> > > > >
> > > > > For us, this is a critical feature, because we need to decide if
> > > > > vhost-pci can be an option at all. In fact, the "exotic ring" will be
> > > > > the only way to provide secure inter-partition communication on
> > > > > Jailhouse.
> > > > If what is here for 2.0 is suitable to be upstream-ed, I think it will
> > > > be easy
> > > > to extend it to 2.1 (probably within 1 month).
> > > Unfortunate ordering here, though. Specifically if we need to modify
> > > existing things instead of just adding something. We will need 2.1 prior
> > > to committing to 2.0 being the right thing.
> > If you want, we can get the common part of design ready first,
> > then we can start to build on the common part at the same time.
> > The draft code of 2.0 is ready. I can clean it up, making it easier for
> > us to continue and change.
> Without going into details yet, a meta requirement for us will be to
> have advanced features optional, negotiable. Basically, we would like to
> minimize the interface to an equivalent of what the ivshmem 2.0 is about
> (there is no need for more in a safe/secure partitioning scenario). At
> the same time, the complexity for a guest should remain low as well.
>
>  From past experience, the only way to ensure that is having a working
> prototype. So I will have to look into enabling that.

OK. Looks like the ordering needs to be changed. This doesn't appear
to be a problem to me.

If the final design doesn't deviate a lot from what's presented here,
I think it should be easy to get 2.1 implemented quickly.
Let's first get the design ready, then assess the effort for
implementation.


Best,
Wei