Re: [virtio-comment] RFC v2: virtio-hostmem: static, guest-owned memory regions

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Frank Yang (lfy@google.com) wrote:
> +Christopher Dall who has tried to standardize goldfish before.
> 
> Link:
> https://github.com/741g/virtio-spec/blob/67602f232386a1782a35b9cb41087586ac3d19e2/virtio-hostmem.tex
> 
> - Security model is pushed to the guest-specific layers like selinux; it is
> possible (and this is useful) for a physical page to be shared across guest
> processes, and it is up to the guest's current security model to enforce
> malicious apps not having access.

I'm not quite sure I understand this or the statement:

   Indeed, it is possible for a malicious guest process to improperly access
   the shared memory of a gralloc/ashmem/dmabuf implementation on virtio-hostmem,
   but we regard that as a flaw in the security model of the guest,
   not the security model of virtio-hostmem.

what's the limit of 'improperly access'.  If that means that it
calls/corrupts/breaks the guest that's fine - if it could DMA over the
host VMM that's not as nice.

I'm also a bit confused by your enumeration/probing.  You say that the
host can refuse a request for a particular CODEC type; that's fine if it
hasn't got it - but can a guest get a list of what the host supports?
(Is that what the 'Device configuration layout' is about or is that
about the  subdevices you already have mapped?)


I don't understand the:
  When the guest starts up, regardless of whether it is plugged in,
  memory regions for each sub-device will be reserved.

  When the hostmem device is plugged in via PCI,
  instance creation/destruction and message sending is allowed.
  Otherwise all operations fail with a guest specific error code.

Say you support hundreds of different codecs - what happens?
I also don't understand what happens before plugging.

(Somewhere near the bottom is the typo notificationotification )

Dave

--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK