All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Roman Kiryanov <rkir@google.com>
Cc: Frank Yang <lfy@google.com>,
	virtio-comment@lists.oasis-open.org,
	Cornelia Huck <cohuck@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: [virtio-comment] Re: RFC: virtio-hostmem (+ Continuation of discussion from [virtio-dev] Memory sharing device)
Date: Mon, 25 Feb 2019 15:34:00 -0500	[thread overview]
Message-ID: <20190225151735-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAOGAQeqGwzRiaqHQG3o3U19p_8S4R=RTjSyxTWqD-2fb677GBg@mail.gmail.com>

On Mon, Feb 25, 2019 at 10:54:03AM -0800, Roman Kiryanov wrote:
> > >   • The host does not back the region at all and a page fault happens.
> >
> > Then what? Guest dies?
> > That doesn't sound reasonable, in particular if you want to
> > allow userspace to map this memory.
> 
> In our implementation we call mmap after asking the host to back the region.

So I guess spec should not say host does not have to back the region
then.


> https://photos.app.goo.gl/NJvPBvvFS3S3n9mn6
> 
> Nothing prevents a guest to call mmap on an unbacked region, then the
> guest will die. If it is possible for the device to figure out if an
> address range
> is backed in VM, the guest driver could talk to the device to fail an mmap
> call if a region is not accessible.

So if driver needs specific knowlegde from the device that needs to be
in the spec.

> > >   • The host has already allocated host RAM (from some source; vkMapMemory,
> > >     malloc(), mmap, etc) memory of some kind and maps a page-aligned host
> > >     pointer to the guest physical address corresponding to the region.
> >
> > I'm not sure what does "of some kind" mean here.
> 
> Memory from any API call that could be used for access through this
> address range.

So just RAM really?

> > Also host and guest might have different ideas about
> > what does page-aligned mean.
> 
> In our implementation we do aligning (for VM operations) and unaligning in the
> guest userspace (because mmap is page aligned) to get the pointer to handle
> pointers in the middle of a page (we have no control on pointers returned
> from a third party API).
> 
> Regards,
> Roman.

I'm not sure how does above answer the comment.  I understand you are
using all kind of APIs internally in your hypervisor but please put
things in terms that can apply to host/guest communication. I can kind
of read it between the lines if I squint hard enough but this makes my
head hurt and there's no guarantee I do it correctly.

To try and put things in your terms, if you try to map a range of memory
you get access to a page that can be bigger than the range you asked
for.  It can cause two ranges to violate a security boundary, cause
information leaks, etc. A library can play with offsets and give a well
behaved application an illusion of a private range but if it ends up
sharing a page of memory with a malicious application then there's no
security boundary between them.

HTH

-- 
MST

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/


  reply	other threads:[~2019-02-25 20:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-24 21:18 [virtio-comment] RFC: virtio-hostmem (+ Continuation of discussion from [virtio-dev] Memory sharing device) Frank Yang
2019-02-24 21:22 ` [virtio-comment] " Frank Yang
2019-02-25  5:15 ` Roman Kiryanov
2019-02-25  5:27 ` [virtio-comment] " Roman Kiryanov
2019-02-25 12:56 ` [virtio-comment] " Dr. David Alan Gilbert
2019-02-25 13:50 ` [virtio-comment] " Michael S. Tsirkin
2019-02-25 18:54   ` Roman Kiryanov
2019-02-25 20:34     ` Michael S. Tsirkin [this message]
2019-02-25 23:08       ` Roman Kiryanov
2019-02-25 23:45         ` Michael S. Tsirkin
2019-03-06 16:36 ` [virtio-comment] " Stefan Hajnoczi
2019-03-06 17:28   ` Michael S. Tsirkin
2019-03-07 17:33     ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190225151735-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=lfy@google.com \
    --cc=rkir@google.com \
    --cc=stefanha@redhat.com \
    --cc=virtio-comment@lists.oasis-open.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.