[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jan Kiszka
Subject: Re: [Qemu-devel] [virtio-dev] Re: Vhost-pci RFC2.0
Date: Wed, 19 Apr 2017 16:52:51 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

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.


 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]