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

[Jan Kiszka]

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.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux