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.
Best,
Wei
