On 2017-04-19 16:33, Wang, Wei W wrote: > On 04/19/2017 07:21 PM, Jan Kiszka wrote: >> 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. >> > > OK, I see most of your story, thanks. To get to the bottom of it, is it > possible to > Sign the packet before put it onto the unreliable channel (e.g. the shared > RX), > Instead of signing in-place? If that's doable, we can have a simpler shared > channel.
Of course, you can always add another copy... But as it was trivial to add unidirectional shared memory support to ivshmem [1], I see no reason this shouldn't be possible for vhost-pci as well. Jan [1] https://github.com/siemens/jailhouse/commit/cfbd0b96d9cdb1ab7246c64bc446be39deb3f087, hypervisor part: hypervisor/include/jailhouse/cell-config.h | 4 ++-- hypervisor/include/jailhouse/ivshmem.h | 2 +- hypervisor/ivshmem.c | 52 +++++++++++++++++++++++++++++++++++----------------- 3 files changed, 38 insertions(+), 20 deletions(-) -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux