OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)


  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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]