[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:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
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
- Re: [Qemu-devel] Vhost-pci RFC2.0, (continued)
- Re: [Qemu-devel] Vhost-pci RFC2.0, Jan Kiszka, 2017/04/19
- Re: [Qemu-devel] Vhost-pci RFC2.0, Wei Wang, 2017/04/19
- Re: [Qemu-devel] [virtio-dev] Re: Vhost-pci RFC2.0, Jan Kiszka, 2017/04/19
- Re: [Qemu-devel] [virtio-dev] Re: Vhost-pci RFC2.0, Wei Wang, 2017/04/19
- Re: [Qemu-devel] [virtio-dev] Re: Vhost-pci RFC2.0, Jan Kiszka, 2017/04/19
- Re: [Qemu-devel] [virtio-dev] Re: Vhost-pci RFC2.0, Wei Wang, 2017/04/19
- Re: [Qemu-devel] [virtio-dev] Re: Vhost-pci RFC2.0, Jan Kiszka, 2017/04/19
- Re: [Qemu-devel] [virtio-dev] Re: Vhost-pci RFC2.0, Wei Wang, 2017/04/19
- Re: [Qemu-devel] [virtio-dev] Re: Vhost-pci RFC2.0, Jan Kiszka, 2017/04/19
- Re: [Qemu-devel] [virtio-dev] Re: Vhost-pci RFC2.0, Wang, Wei W, 2017/04/19
- Re: [Qemu-devel] [virtio-dev] Re: Vhost-pci RFC2.0,
Jan Kiszka <=
- Re: [Qemu-devel] [virtio-dev] Re: Vhost-pci RFC2.0, Wei Wang, 2017/04/20
- Re: [Qemu-devel] [virtio-dev] Re: Vhost-pci RFC2.0, Jan Kiszka, 2017/04/20
- Re: [Qemu-devel] [virtio-dev] Re: Vhost-pci RFC2.0, Wei Wang, 2017/04/20
Re: [Qemu-devel] [virtio-dev] Vhost-pci RFC2.0, Stefan Hajnoczi, 2017/04/19