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

[Jan Kiszka]

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