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

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/