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

[Wei Wang <wei.w.wang@intel.com>]

On 04/20/2017 03:05 PM, Jan Kiszka wrote:
> On 2017-04-20 08:51, Wei Wang wrote:
>> On 04/19/2017 10:52 PM, Jan Kiszka wrote:
>>> 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.
>>>
>> IIUC, this requires the ring and it's head/tail to be put into different
>> regions, it would
>> be hard to fit the existing virtqueue into the shared the channel, since
>> the vring and
>> its pointers (e.g. idx) and flags are on the same page.
>> So, probably will need to use another ring type.
> The current virtio spec allows this split already - though it may not be
> lived by existing implementations (we do, though, in ivshmem-net).
> Future virtio spec (1.1 IIRC) will require a third region that holds the
> meta data and has to be writable by both sides. But it will remain
> possible to keep outgoing and incoming payload in separate pages, thus
> with different access permissions.
>
Yes, need to change some implementation. Will give it a try later.


Best,
Wei