On 2017-04-19 13:11, Wei Wang wrote: > 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?
It can swallow it, "steal" it (redirect), but it can't manipulate the signed content without being caught, that's the idea. It's particularly relevant for safety-critical traffic from one safe application to another over unreliable channels, but it may also be relevant for the integrity of messages in a secure setup. > >>>>>>>>> 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. > OK, thanks. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org