Re: [PATCH RFC 00/15] vhost-user: isolated memory

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1959 bytes --]

On 7/23/26 18:29, ConKite wrote:
> This patch series implements a memory isolation mode in vhost-user. The
> purpose of this mode is to provide the option of additional security by
> eliminating direct access of guest memory by vhost-user devices.
> At a high level this works by:
> 
> 1. Adding qdev and qapi properties required to enable isolation mode for
>    various devices.
> 2. Allocating an isolation memory region in an anonymous file and mapping it
>    to host memory.  This isolation region will hold the bounce buffers and
>    vrings necessary to move data.
> 3. Using a vhost-iova-tree to allocate and track the mapping between
>    guest regions and their corresponding bounce buffers in the isolation
>    memory.
> 4. Creating shadow virtqueues to intercept request notifications.  As
>    kick and call events are received by an svq, it copies buffer
>    contents and descriptors between isolation and guest memory before
>    notifying the backend or guest.   
> 
> Note: This project is currently in a partially functional state. For
> example, in testing vhost-user-input and a keyboard, keystrokes may
> register correctly or be double counted depending on the combination
> of backend daemon and guest OS used. However, the desire is to make
> this work public at this stage for comment on the overall
> approach.

Thank you so much for the work!  I'm very excited about it.

I do have a few questions:

1. Is this dependent on the specific vhost-user device type?  In other
   words, does this code need to be specific to vhost-user-blk/net/etc
   devices?

2. What kind of performance penalty is there for isolation?  The use
   of shadow virtqueues seems relatively complex.

3. Does it make sense to have device-type-specific code to validate
   data sent back by the server?  This could protect drivers that
   trust virtio devices. 
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]