All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: "Stefan Hajnoczi" <stefanha@redhat.com>,
	"Zach Reizner" <zachr@chromium.org>,
	"David Stevens" <stevensd@chromium.org>,
	"Stéphane Marchesin" <marcheu@chromium.org>,
	"Tomeu Vizoso" <tomeu.vizoso@collabora.com>,
	"Tomasz Figa" <tfiga@chromium.org>,
	virtio-dev@lists.oasis-open.org,
	"Alexandros Frantzis" <alexandros.frantzis@collabora.co.uk>
Subject: Re: [virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)
Date: Mon, 17 Feb 2020 13:32:16 +0100	[thread overview]
Message-ID: <20200217123216.bdojgvvnpw34kmgp@sirius.home.kraxel.org> (raw)
In-Reply-To: <20200217112838.1699d5ce@collabora.com>

  Hi,

> As pointed in my reply to David's email, I'm a bit worried by the
> security implications of this approach. As long as the dmabuf -> UUID
> conversion stays in kernel space we should be safe, but if we start
> allowing a guest proxy (running in userland) to send raw UUIDs on a
> VSOCK connection, we lose the ability to check if the process is
> actually allowed to use this resource.

Correct.

The UUID namespace is huge (128bit), so playing guessing games to access
resources you don't own isn't exactly trivial.  I would not be concerned
too much.  If you want avoid uuids nevertheless the only way is option
#1 (extent vsock) I think.

> to attach UUIDs to resources. This could be addressed with the
> virtio-dmabuf infrastructure you proposed, but it looks like David's
> proposal does not generalize this interface (it's a virtio-gpu-only
> thing right now).

The idea is that virtio-gpu guest driver adds a uuid to any dma-buf it
exports.  Then other drivers importing the dma-buf can figure what the
uuid is.  We could also add a ioctl (on the dma-buf fd) to query the
uuid.

> > Also it is a fact that approach #1 didn't went anywhere so far but we
> > have a working implementation of approach #3.  So I guess I wouldn't
> > veto approach #3 if you pick it after evaluating the options on the
> > table.
> 
> I'd really like to investigate option #1, unless you have strong
> reasons to think this is a dead end.

Last time I discussed this with Stefan Hajnoczi he didn't like the idea
too much.  IIRC the main concern was that it would work on specific
kinds of file handles only and that vsock would need special support
code for every file handle type.

It quite a while ago though, maybe time for a re-evaluation.  The
limitation to specific file handles wouldn't go away, and likewise the
need for special support code.  We have a more clear plan for dma-buf
support though.  Also we got virtio-fs meanwhile and being able to pass
virtio-fs file handles over vsock looks like a pretty cool feature to
me.

Stefan?

cheers,
  Gerd


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2020-02-17 12:32 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-07 17:28 [virtio-dev] [RFC] Upstreaming virtio-wayland (or an alternative) Boris Brezillon
2020-02-10  5:06 ` [virtio-dev] " David Stevens
2020-02-17 10:02   ` Boris Brezillon
2020-02-17 10:22     ` David Stevens
2020-02-10 13:38 ` Gerd Hoffmann
2020-02-10 16:09   ` Stefan Hajnoczi
2020-02-17 10:28   ` Boris Brezillon
2020-02-17 12:32     ` Gerd Hoffmann [this message]
2020-02-17 13:44       ` Boris Brezillon
     [not found] ` <CADMs+9YC3QHOsmsB9pjA-AFC+fc=_a+tSqBbDsecNvkhBc85Dw@mail.gmail.com>
2020-02-17 11:02   ` Boris Brezillon
2020-02-17 13:58 ` Boris Brezillon
     [not found]   ` <CAFNex=BuHdsEjFK3_cTqO2nOE-kB_MSH26sCTekF_6AK8Fyv3Q@mail.gmail.com>
2020-02-17 18:21     ` Boris Brezillon
     [not found]       ` <CAFNex=A8fU3e=FYP=t7jQ0J2E5aoyGKujhj8Df+vOhkzV8etgA@mail.gmail.com>
2020-02-19  8:52         ` Boris Brezillon
2020-02-24 10:33       ` Boris Brezillon
2020-02-24 12:12         ` Gerd Hoffmann
2020-02-24 12:45           ` Boris Brezillon
2020-02-24 13:18             ` Boris Brezillon
2020-02-24 13:42               ` Gerd Hoffmann
2020-02-24 13:57                 ` Boris Brezillon
2020-02-24 14:25                   ` Boris Brezillon
2020-02-24 13:35             ` Gerd Hoffmann
2020-02-24 12:32       ` Gerd Hoffmann
2020-02-25 15:21 ` [virtio-dev] " Boris Brezillon
2020-02-25 15:55   ` Alex Bennée
2020-02-26  9:25     ` Boris Brezillon
2020-02-26 15:12   ` Gerd Hoffmann
2020-02-26 17:05     ` Boris Brezillon
2020-02-27 10:29       ` Gerd Hoffmann
2020-02-27 12:24         ` Boris Brezillon
2020-02-27  4:20   ` David Stevens
2020-02-27  9:09     ` Boris Brezillon
     [not found]       ` <CAFNex=C4wm7=iH9XmyHoTSdkDfA3vbFOuLaaQ4aLjE9keu_NDg@mail.gmail.com>
2020-02-27  9:33         ` Boris Brezillon
2020-02-27 11:14       ` David Stevens
2020-02-27 11:51         ` Boris Brezillon
2020-02-27 14:43         ` Gerd Hoffmann
2020-02-28  8:04           ` Boris Brezillon
2020-02-28  9:27             ` Gerd Hoffmann
2020-02-28 10:11               ` David Stevens
2020-02-28 10:30                 ` Gerd Hoffmann
2020-03-02  2:24                   ` David Stevens
2020-03-02  9:28                     ` Boris Brezillon
2020-02-28 10:31                 ` Boris Brezillon

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=20200217123216.bdojgvvnpw34kmgp@sirius.home.kraxel.org \
    --to=kraxel@redhat.com \
    --cc=alexandros.frantzis@collabora.co.uk \
    --cc=boris.brezillon@collabora.com \
    --cc=marcheu@chromium.org \
    --cc=stefanha@redhat.com \
    --cc=stevensd@chromium.org \
    --cc=tfiga@chromium.org \
    --cc=tomeu.vizoso@collabora.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=zachr@chromium.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.