Re: [virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)
On Mon, 24 Feb 2020 14:57:43 +0100 Boris Brezillon wrote: > On Mon, 24 Feb 2020 14:42:31 +0100 > Gerd Hoffmann wrote: > > > Hi, > > > > > > But let's say we go for a dedicated virtio-device to preserve this > > > > granularity. Should we aim at providing a generic virtio-msg device or > > > > should we keep this so-called wayland-specific virtio device (I'd like > > > > to remind you that it's actually protocol-agnostic)? > > > > > > Maybe there's another option (not sure I mentioned it previously): > > > de-correlate the message passing and fd-passing interfaces. If we add a > > > virtio-fd device that takes care of FD passing between guest and host, > > > we can still use a regular vsock to pass messages (can be vhost or > > > !vhost depending on your level of paranoïa). The wayland proxies would > > > then queue/dequeue messages to/from the vsock and FDs to/from virtio-fd. > > > > > > > Hmm, I suspect supporting unix socket passing (by creating a tunnel for > > them) is going to be tricky in with that approach. > > Yes, If you want a generic vsock <-> unix proxy, you'll have to > encapsulate the 'message+number of FDs passed' information so the other > end knows how many FDs should be dequeued on the virtio-fd dev. The > other option being to implement proxies that can parse the messages and > extract the 'number of FDs' from there. Nevermind, I misunderstood your concern. Indeed, supporting unix FD passing would be trickier (you'd need to attach both a vosck and a virtio-fd instance). - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)
On Mon, 24 Feb 2020 14:42:31 +0100 Gerd Hoffmann wrote: > Hi, > > > > But let's say we go for a dedicated virtio-device to preserve this > > > granularity. Should we aim at providing a generic virtio-msg device or > > > should we keep this so-called wayland-specific virtio device (I'd like > > > to remind you that it's actually protocol-agnostic)? > > > > Maybe there's another option (not sure I mentioned it previously): > > de-correlate the message passing and fd-passing interfaces. If we add a > > virtio-fd device that takes care of FD passing between guest and host, > > we can still use a regular vsock to pass messages (can be vhost or > > !vhost depending on your level of paranoïa). The wayland proxies would > > then queue/dequeue messages to/from the vsock and FDs to/from virtio-fd. > > Hmm, I suspect supporting unix socket passing (by creating a tunnel for > them) is going to be tricky in with that approach. Yes, If you want a generic vsock <-> unix proxy, you'll have to encapsulate the 'message+number of FDs passed' information so the other end knows how many FDs should be dequeued on the virtio-fd dev. The other option being to implement proxies that can parse the messages and extract the 'number of FDs' from there. - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)
Hi, > But let's say we go for a dedicated virtio-device to preserve this > granularity. Should we aim at providing a generic virtio-msg device or > should we keep this so-called wayland-specific virtio device (I'd like > to remind you that it's actually protocol-agnostic)? I think it totally makes sense to have something protocol-agnostic, especially given that people figured it isn't really wayland-specific and already using the existing implementation for non-wayland things. cheers, Gerd - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)
On Mon, 24 Feb 2020 13:45:13 +0100 Boris Brezillon wrote: > On Mon, 24 Feb 2020 13:12:55 +0100 > Gerd Hoffmann wrote: > > > On Mon, Feb 24, 2020 at 11:33:48AM +0100, Boris Brezillon wrote: > > > On Mon, 17 Feb 2020 19:21:50 +0100 > > > Boris Brezillon wrote: > > > > > > > > > Thats why I don't like the new virtio device idea much and would > > > > > > prefer > > > > > > vhost being reused, either directly (#1) or via proxy (#2). > > > > > > > > > > For crosvm's purposes, we are looking at ways to reduce vhost usage in > > > > > order to reduce host kernel exposure to untrusted guest input, > > > > > including from the guest kernel. That is why a non-vhost based > > > > > solution would be prefered. > > > > > > > > Okay, I didn't know you were avoiding vhost-based solutions to > > > > reduce the attack surface. > > > > > > Looks like they implemented vhost-less vsock in Firecracker[1]. Not > > > sure how much work that would be to port this implementation to crosvm, > > > but maybe that's an option. > > > > > > [1]https://github.com/firecracker-microvm/firecracker/pull/1176 > > > > Well, the nice thing about vsock is that (a) you have the same interface > > on guest and host, and (b) it is hypervisor-agnostic. Applications can > > simply use the usual system calls (socket, bind, listen, connect) with > > AF_VSOCK socket type and be done with it. > > > > When not using vhost this goes away (on the host side). firecracker > > seems to have a vsock <-> unix socket bridge in vmm userspace instead > > (pull req msg sounds like that, didn't check the code). > > That's also my understanding. Note that you still keep the genericity > on the guest side, which is a good thing I guess. > > > > > I think there can be only one vsock device per guest. So you can't have > > multiple instances, one with a vsock backend on the host and one with a > > userspace backend on the host, then pick one of the two depending on the > > use case. > > > > So, one advantage of a separate device would be that we'll gain some > > flexibility in terms of the host side implementation. vsock vhost can > > be used together with a wayland userspace backend. > > Yes, though if you really want to avoid vhost to reduce the attack > surface, you'll probably want to never use vhost instead of having this > restriction on a per-use-case basis. > > But let's say we go for a dedicated virtio-device to preserve this > granularity. Should we aim at providing a generic virtio-msg device or > should we keep this so-called wayland-specific virtio device (I'd like > to remind you that it's actually protocol-agnostic)? Maybe there's another option (not sure I mentioned it previously): de-correlate the message passing and fd-passing interfaces. If we add a virtio-fd device that takes care of FD passing between guest and host, we can still use a regular vsock to pass messages (can be vhost or !vhost depending on your level of paranoïa). The wayland proxies would then queue/dequeue messages to/from the vsock and FDs to/from virtio-fd. - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)
Hi, > > Because wayland benefits from allocation and sharing of > > virtio-gpu buffers, a virtio-gpu combo device simplifies access to > > those buffers, whereas the separate virtio devices as implemented in > > crosvm requires bridging of resource handles (in guest kernel) and FDs > > (in crosvm). > > I must admit I'm not a huge fan of integrating a protocol-agnostic > message passing interface (with FD-passing support) to virtio-gpu. > Sounds like something that could be re-used without virtio-gpu being > involved to me. Agree. > As for the resource bridging thing, that's more or less > what I proposed with the generic interface to translate resource handles > (what I called VFDs) to local FDs. Yes, I think it makes sense to figure a sensible way to translate/manage resource handles and have multiple virtio device work together. What if you want pass a handle to a virtio-fs file instead of a virtio-gpu dma-buf between host and guest? cheers, Gerd - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)
On Mon, 17 Feb 2020 19:21:50 +0100 Boris Brezillon wrote: > > > Thats why I don't like the new virtio device idea much and would prefer > > > vhost being reused, either directly (#1) or via proxy (#2). > > > > For crosvm's purposes, we are looking at ways to reduce vhost usage in > > order to reduce host kernel exposure to untrusted guest input, > > including from the guest kernel. That is why a non-vhost based > > solution would be prefered. > > Okay, I didn't know you were avoiding vhost-based solutions to > reduce the attack surface. Looks like they implemented vhost-less vsock in Firecracker[1]. Not sure how much work that would be to port this implementation to crosvm, but maybe that's an option. [1]https://github.com/firecracker-microvm/firecracker/pull/1176 - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)
On Tue, 18 Feb 2020 13:15:04 -0800 Zach Reizner wrote: > >> I don't think extending vsock is a > >> good idea because there's enough going on with virtio-wayland with > >> respect to FD passing and emulation that a generic interface will be > >> too opinionated. > > > > Can you be more specific? What would be the limitations of such a > > generic interface that would make it unusable for the virtio-wayland > > use case? > > What I meant by that statement was that virtio-wayland implements > jst enough FD semantics to make wayland work. It's true that some > other protocols also work over virtio-wayland, but that was a > combination of filling in the holes for that protocol and coincidence. > I'm afraid that a generic interface would have to contend with a long > tail of FD semantics that don't line up with most other protocols. To > give you a specific example, when virtio-wayland encounters an FD in > the guest->host direction that it doesn't recognize, but that can be > written or read to, it will create a unix pipe on the host side and > send it along the wayland connection. This choice works fine for > wayland, but that's because that was the entire point of the design. A > more generic system would have to realize that interaction more > authentically (e.g. for sending a bi-directional socket), Indeed, but is that really a bad thing? I mean, do we really want any kind of FD to transit between guest and host as soon as they implement ->read/write(). For instance, should we forward device FDs which have ->read/write() implemented but on which guest users might want to call ioctl(). > and I'm not > sure it's going to be possible. > > > > > > I like the combination with virtio-gpu because it > > > already has two related but separate graphics concepts combined into > > > one device (display and rendering), so wayland would feel right at > > > home. > > > > Except that, looking at the virtio-wayland code nothing in there looks > > fundamentally wayland specific, or even display-server specific. Sure, > > FD passing support is focused on what wayland needs (pipes, dmabuf FDs, > > ...), but I see nothing that would prevent making it generic enough to > > pass other kind of resources if we ever need to. > > That was intentional, and you have a good point. The reason I was > suggesting integration with virtio-gpu was because I saw that as the > most viable path towards upstreaming. It seems that creating a > dedicated virtio device is highly contentious. > > > > > I must admit I'm not a huge fan of integrating a protocol-agnostic > > message passing interface (with FD-passing support) to virtio-gpu. > > Sounds like something that could be re-used without virtio-gpu being > > involved to me. As for the resource bridging thing, that's more or less > > what I proposed with the generic interface to translate resource handles > > (what I called VFDs) to local FDs. It would probably be easier with a > > vhost-based solution, but your resource bridge interface in crosvm > > seems to provide the same kind of abstraction. Any reason you want to > > avoid this split? > > If the upstreamed version of this actually becomes agnostic, than > keeping it separate from virtio-gpu would make the most sense, but > that seems to be unsettled. Gerd, Stefan, any comment? - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)
On Mon, 17 Feb 2020 09:47:46 -0800 Zach Reizner wrote: > > Thats why I don't like the new virtio device idea much and would prefer > > vhost being reused, either directly (#1) or via proxy (#2). > > For crosvm's purposes, we are looking at ways to reduce vhost usage in > order to reduce host kernel exposure to untrusted guest input, > including from the guest kernel. That is why a non-vhost based > solution would be prefered. Okay, I didn't know you were avoiding vhost-based solutions to reduce the attack surface. > > > Any potential security hole should be considered IMHO, even if it's not > > easily exploitable. > > I second Boris's statement. In the age of Spectre-like exploits, > keeping secrets from other processes should be considered riskier than > using FDs to prove that a process can access a resource. > > > We might be able to do that lazily if we add > > ->virtio_fd_to_vfd()/->virtio_vfd_to_fd() hooks to the file_operations > > struct, instead of expecting the subsystem to pro-actively create those > > mappings (when those hooks are not implemented, that means the resource > > backed by this FD can't be passed on a VSOCK). > > virtio-wayland actually will handle passing arbitrary FDs back and > forth, but it does have special handling for virtio-gpu dmabufs. For > everything else, virtio-wayland will determine if the FD is > readable/writable/mappable and will recreate a pipe/memfd on the other > side to emulate the FD. For mappable FDs, this is limited host->guest > passing because in practice this is used only by the compositor to > send the keyboard mapping to clients. The pipes are needed for both > host->guest and guest->host because they are used to request clipboard > content. The only FDs that require special handling are ones where > there already is a host-side FD corresponding to the guest side FD, > such as the case of wayland socket connections or dmabufs. > > As for the question of which solution to go for, I would suggest > either 3 (dedicated virtio device) or combining features from > virtio-wayland with virtio-gpu. I don't think extending vsock is a > good idea because there's enough going on with virtio-wayland with > respect to FD passing and emulation that a generic interface will be > too opinionated. Can you be more specific? What would be the limitations of such a generic interface that would make it unusable for the virtio-wayland use case? > I like the combination with virtio-gpu because it > already has two related but separate graphics concepts combined into > one device (display and rendering), so wayland would feel right at > home. Except that, looking at the virtio-wayland code nothing in there looks fundamentally wayland specific, or even display-server specific. Sure, FD passing support is focused on what wayland needs (pipes, dmabuf FDs, ...), but I see nothing that would prevent making it generic enough to pass other kind of resources if we ever need to. > Because wayland benefits from allocation and sharing of > virtio-gpu buffers, a virtio-gpu combo device simplifies access to > those buffers, whereas the separate virtio devices as implemented in > crosvm requires bridging of resource handles (in guest kernel) and FDs > (in crosvm). I must admit I'm not a huge fan of integrating a protocol-agnostic message passing interface (with FD-passing support) to virtio-gpu. Sounds like something that could be re-used without virtio-gpu being involved to me. As for the resource bridging thing, that's more or less what I proposed with the generic interface to translate resource handles (what I called VFDs) to local FDs. It would probably be easier with a vhost-based solution, but your resource bridge interface in crosvm seems to provide the same kind of abstraction. Any reason you want to avoid this split? - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)
On Fri, 7 Feb 2020 18:28:42 +0100 Boris Brezillon wrote: > Based on all previous discussions, I could identify 3 different > approaches: > > 1/ Use VSOCK and extend it to support passing (some) FDs > 2/ Use a user space VSOCK-based proxy that's in charge of >a/ passing regular messages >b/ passing specific handles to describe objects shared > between host and guest (most focus has been on dmabufs as > this is what we really care about for the gfx use case, > but other kind of FDs can be emulated through a > VSOCK <-> UNIX_SOCK bridging) > 3/ Have a dedicated kernel space solution that provides features >exposed by #1 but through a virtio device interface (basically >what virtio-wayland does today) > > Each of them has its pros and cons, which I'll try to sum-up (please > correct me if I'm wrong, and add new things if you think they are > missing). > > #1 might require extra care if we want to make it safe, as pointed > out by Stefan here [4] (but I wonder if the problem is not the same > for a virtio-wayland based solution). Of course you also need a bit of > infrastructure to register FD <-> VFD mappings (VFD being a virtual > file descriptor that's only used as unique IDs identifying the resource > backed by the local FD). FD <-> VFD mappings would have to be created > by the subsystem in charge of the object backing the FD (virtio-gpu for > exported GEM buffers, virtio-vdec for video buffers, vsock for unix > sockets if we decide to bridge unix and vsock sockets to make it > transparent, ...). The FD <-> VFD mapping would also have to be created > on the host side, probably by the virtio device implementation > (virglrenderer for GEM bufs for instance), which means host and guest > need a way to inform the other end that a new FD <-> VFD mapping has > been created so the other end can create a similar mapping (I guess this > requires extra device-specific commands to work). We might be able to do that lazily if we add ->virtio_fd_to_vfd()/->virtio_vfd_to_fd() hooks to the file_operations struct, instead of expecting the subsystem to pro-actively create those mappings (when those hooks are not implemented, that means the resource backed by this FD can't be passed on a VSOCK). Anyway, that's just an implementation detail, the first question being, should we pursue in this direction or not? - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)
On Mon, 17 Feb 2020 13:32:16 +0100 Gerd Hoffmann wrote: > 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. It depends on the UUID algorithm [1] I guess. Versions 1, 2, 3 and 5 seem easier to guess than version 4 (not sure which one you're planning to use here). > I would not be concerned > too much. Any potential security hole should be considered IMHO, even if it's not easily exploitable. > 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. Okay. > > > > 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. According to [2], he was more worried by the risk of DoS than the fact that only some FDs might be able to transit on a VSOCK (which I find totally reasonable BTW, since it requires some coordination between host and guest to get that working). > > 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? > [1]https://en.wikipedia.org/wiki/Universally_unique_identifier [2]https://www.spinics.net/lists/kvm/msg159206.html - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
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 - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)
Hi Stéphane, On Mon, 10 Feb 2020 12:01:02 -0800 Stéphane Marchesin wrote: > On Fri, Feb 7, 2020 at 9:28 AM Boris Brezillon < > boris.brezil...@collabora.com> wrote: > > > Hello everyone, > > > > I recently took over Tomeu's task of upstreaming virtio-wayland. After > > spending quite a bit of time collecting information from his different > > attempts [1][2] I wanted to sync with all the people that were involved > > in the previous discussions (if I missed some of them, feel free to add > > them back). > > > > The goal here is to get a rough idea of the general direction this > > should take so I can start implementing a PoC and see if it fits > > everyone's needs. > > > > virtio-wayland [3] started as a solution to pass wayland messages > > between host and guests so the guest can execute wayland apps whose > > surface buffers are passed to the wayland compositor running on the > > host. While this was its primary use case, I've heard it's been used to > > transport other protocols. And that's not surprising, when looking at > > the code I noticed it was providing a protocol-agnostic message passing > > interface between host and guests, similar to what VSOCK provides but > > with FD passing as an extra feature. > > > > Based on all previous discussions, I could identify 3 different > > approaches: > > > > 1/ Use VSOCK and extend it to support passing (some) FDs > > 2/ Use a user space VSOCK-based proxy that's in charge of > >a/ passing regular messages > >b/ passing specific handles to describe objects shared > > between host and guest (most focus has been on dmabufs as > > this is what we really care about for the gfx use case, > > but other kind of FDs can be emulated through a > > VSOCK <-> UNIX_SOCK bridging) > > 3/ Have a dedicated kernel space solution that provides features > >exposed by #1 but through a virtio device interface (basically > >what virtio-wayland does today) > > > > Each of them has its pros and cons, which I'll try to sum-up (please > > correct me if I'm wrong, and add new things if you think they are > > missing). > > > > #1 might require extra care if we want to make it safe, as pointed > > out by Stefan here [4] (but I wonder if the problem is not the same > > for a virtio-wayland based solution). Of course you also need a bit of > > infrastructure to register FD <-> VFD mappings (VFD being a virtual > > file descriptor that's only used as unique IDs identifying the resource > > backed by the local FD). FD <-> VFD mappings would have to be created > > by the subsystem in charge of the object backing the FD (virtio-gpu for > > exported GEM buffers, virtio-vdec for video buffers, vsock for unix > > sockets if we decide to bridge unix and vsock sockets to make it > > transparent, ...). The FD <-> VFD mapping would also have to be created > > on the host side, probably by the virtio device implementation > > (virglrenderer for GEM bufs for instance), which means host and guest > > need a way to inform the other end that a new FD <-> VFD mapping has > > been created so the other end can create a similar mapping (I guess this > > requires extra device-specific commands to work). Note that this > > solution doesn't look so different from the virtio-dmabuf [5] approach > > proposed by Gerd a few months back, it's just extended to be a global > > VFD <-> FD registry instead of a dmabuf <-> unique-handle one. One > > great thing about this approach is that we can re-use it for any kind > > of FD sharing, not just dmabufs. > > > > #2 is a bit challenging, since it requires the proxy to know about all > > possible kind of FDs and do a FD <-> unique handle conversion with some > > help from the subsystem backing the FD. For dmabufs, that means we > > need to know who created the dmabuf, or assume that only one device is > > used for all allocations (virtio-gpu?). AFAIU, there's also a security > > issue as one could pass random (but potentially valid) handles to the > > host proxy (pointed out by Tomasz [6]). > > > > #3 is pretty similar to #1 in its design except that, instead of using > > the VSOCK infrastructure it's using a new type of virtio device. I > > guess it has the same pros and cons #1 has, and the name should probably > > be changed to reflect the fact that it can transmit any kind of data not > > just wayland. > > > > This is just a high level view of the problem and the solutions proposed > > by various people over the years. I'm sure I'm missing tons of details > > and don't realize yet all the complexity behind solution #1, but looking > > at this summary, I wonder if I should investigate this solution in > > priority. An alternative could be to rebrand virtio-wayland, but as I > > said, it's close enough to VSOCK to try to merge the missing features > > in VSOCK instead. This being said, I'm not yet set on any of those > > solutions, and the point of this email is to see with all of
Re: [virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)
Hi Gerd, Sorry for the delay, I was OOO last week. On Mon, 10 Feb 2020 14:38:56 +0100 Gerd Hoffmann wrote: > Hi, > > > #1 might require extra care if we want to make it safe, as pointed > > out by Stefan here [4] (but I wonder if the problem is not the same > > for a virtio-wayland based solution). Of course you also need a bit of > > infrastructure to register FD <-> VFD mappings (VFD being a virtual > > file descriptor that's only used as unique IDs identifying the resource > > backed by the local FD). FD <-> VFD mappings would have to be created > > by the subsystem in charge of the object backing the FD (virtio-gpu for > > exported GEM buffers, virtio-vdec for video buffers, vsock for unix > > sockets if we decide to bridge unix and vsock sockets to make it > > transparent, ...). The FD <-> VFD mapping would also have to be created > > on the host side, probably by the virtio device implementation > > (virglrenderer for GEM bufs for instance), which means host and guest > > need a way to inform the other end that a new FD <-> VFD mapping has > > been created so the other end can create a similar mapping (I guess this > > requires extra device-specific commands to work). Note that this > > solution doesn't look so different from the virtio-dmabuf [5] approach > > proposed by Gerd a few months back, it's just extended to be a global > > VFD <-> FD registry instead of a dmabuf <-> unique-handle one. One > > great thing about this approach is that we can re-use it for any kind > > of FD sharing, not just dmabufs. > > A dedicated is most likely not going to happen. Probably virtio-gpu and > possibly other devices too will support attaching a unique handle (a > uuid probably) to a dma-buf, then share buffers like this: > > (1) guest userspace export virtio-gpu resource as dma-buf > (2) guest kernel generates uuid, sends uuid to the host (or maybe we > let the host generate the uuid, not clear yet), attaches it to > the (guest) dma-buf. > (3) guest userspace imports the dma-buf into virtio-vdev > (4) virtio-vdec driver finds the uuid attached to the buffer and passes > it on to the host, > (5) virtio-vdev device can use the uuid to lookup the buffer on the > host, then have the host decoder send the data directly to the > host gpu ... > > It certainly makes sense to use this for wayland too, so you just pass > around the uuid if you want pass around a dma-buf (no matter which of > the three solutions). 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. Those checks happen kernel side when a FD is passed on a UNIX socket, which guarantees that the process passing this FD actually has access to this resource (either because it created it or because someone else passed the resource through another UNIX socket). Are we expecting that the wayland proxy runs with high privilege (root?), and do we have a way to enforce that at the VSOCK level? > > > #2 is a bit challenging, since it requires the proxy to know about all > > possible kind of FDs and do a FD <-> unique handle conversion with some > > help from the subsystem backing the FD. For dmabufs, that means we > > need to know who created the dmabuf, or assume that only one device is > > used for all allocations (virtio-gpu?). > > See above, the uuid idea should simplify this. Well, it gets more complicated if you start adding allocators (we currently only have virtio-gpu, but what if virtio-vdec starts providing its own buffer allocator) and don't add a generic interface 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). > > > #3 is pretty similar to #1 in its design except that, instead of using > > the VSOCK infrastructure it's using a new type of virtio device. I > > guess it has the same pros and cons #1 has, and the name should probably > > be changed to reflect the fact that it can transmit any kind of data not > > just wayland. > > Even though vsock looks simple at first it isn't when you look at the > details. You'll want support more streams than virtqueues. So you'll > go multiplex. You want good performance, but you also don't want allow > streams to DoS the device by filling up the queue. > > Thats why I don't like the new virtio device idea much and would prefer > vhost being reused, either directly (#1) or via proxy (#2). Okay. > > Note that vhost aims to be hypervisor-agnostic and we have (unless I > missed something) three transports for it: virtio, vmware and hyperv. > So extending that with
[virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)
> > > FD <-> VFD mappings would have to be created > > > by the subsystem in charge of the object backing the FD (virtio-gpu for > > > exported GEM buffers, virtio-vdec for video buffers, vsock for unix > > > sockets if we decide to bridge unix and vsock sockets to make it > > > transparent, ...). The FD <-> VFD mapping would also have to be created > > > on the host side, probably by the virtio device implementation > > > (virglrenderer for GEM bufs for instance), which means host and guest > > > need a way to inform the other end that a new FD <-> VFD mapping has > > > been created so the other end can create a similar mapping (I guess this > > > requires extra device-specific commands to work). > > > > My recent proposal for cross device resource sharing seems like it > > could be relevant here: https://markmail.org/thread/jsaoqy7phrqdcpqu. > > Thanks for sharing this link. I had a quick look at this proposal, and, > maybe I'm wrong, but I'm not sure it actually addresses Tomasz' concern > [1] if we keep letting a userspace proxy do the FD <-> UUID conversion > and sending the UUID through the VSOCK. To me, a UUID only guarantees > that 2 buffers will get different UUIDs (assuming they use the same > algorithm to generate this UUID), but nothing prevents a malicious app > from opening a connection to the host proxy and sending valid wayland > messages with forged UUIDs, in the hope that one of them will match an > already exported resource. You're correct that it wouldn't really protect against malicious apps. My email was more about pointing out a mechanism that could potentially help address the FD <-> VFD mapping. -David - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)
Hi David, On Mon, 10 Feb 2020 14:06:21 +0900 David Stevens wrote: > > FD <-> VFD mappings would have to be created > > by the subsystem in charge of the object backing the FD (virtio-gpu for > > exported GEM buffers, virtio-vdec for video buffers, vsock for unix > > sockets if we decide to bridge unix and vsock sockets to make it > > transparent, ...). The FD <-> VFD mapping would also have to be created > > on the host side, probably by the virtio device implementation > > (virglrenderer for GEM bufs for instance), which means host and guest > > need a way to inform the other end that a new FD <-> VFD mapping has > > been created so the other end can create a similar mapping (I guess this > > requires extra device-specific commands to work). > > My recent proposal for cross device resource sharing seems like it > could be relevant here: https://markmail.org/thread/jsaoqy7phrqdcpqu. Thanks for sharing this link. I had a quick look at this proposal, and, maybe I'm wrong, but I'm not sure it actually addresses Tomasz' concern [1] if we keep letting a userspace proxy do the FD <-> UUID conversion and sending the UUID through the VSOCK. To me, a UUID only guarantees that 2 buffers will get different UUIDs (assuming they use the same algorithm to generate this UUID), but nothing prevents a malicious app from opening a connection to the host proxy and sending valid wayland messages with forged UUIDs, in the hope that one of them will match an already exported resource. Regards, Boris [1]https://www.spinics.net/lists/kvm/msg185688.html - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)
On Mon, Feb 10, 2020 at 02:38:56PM +0100, Gerd Hoffmann wrote: > > #3 is pretty similar to #1 in its design except that, instead of using > > the VSOCK infrastructure it's using a new type of virtio device. I > > guess it has the same pros and cons #1 has, and the name should probably > > be changed to reflect the fact that it can transmit any kind of data not > > just wayland. > > Even though vsock looks simple at first it isn't when you look at the > details. You'll want support more streams than virtqueues. So you'll > go multiplex. You want good performance, but you also don't want allow > streams to DoS the device by filling up the queue. > > Thats why I don't like the new virtio device idea much and would prefer > vhost being reused, either directly (#1) or via proxy (#2). > > Note that vhost aims to be hypervisor-agnostic and we have (unless I > missed something) three transports for it: virtio, vmware and hyperv. > So extending that with virtio-only features might not be the best idea. s/vsock/vhost/ > 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. > > Final note: We have a new kid on the block: virtio-fs. I think > virtio-fs with dax enabled should allow for shared file mappings between > host and guest. That is something a proxy (#2) might be able to make > use of. Yes, virtio-fs allows the guest to directly map files from the host. Stefan signature.asc Description: PGP signature
[virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)
Hi, > #1 might require extra care if we want to make it safe, as pointed > out by Stefan here [4] (but I wonder if the problem is not the same > for a virtio-wayland based solution). Of course you also need a bit of > infrastructure to register FD <-> VFD mappings (VFD being a virtual > file descriptor that's only used as unique IDs identifying the resource > backed by the local FD). FD <-> VFD mappings would have to be created > by the subsystem in charge of the object backing the FD (virtio-gpu for > exported GEM buffers, virtio-vdec for video buffers, vsock for unix > sockets if we decide to bridge unix and vsock sockets to make it > transparent, ...). The FD <-> VFD mapping would also have to be created > on the host side, probably by the virtio device implementation > (virglrenderer for GEM bufs for instance), which means host and guest > need a way to inform the other end that a new FD <-> VFD mapping has > been created so the other end can create a similar mapping (I guess this > requires extra device-specific commands to work). Note that this > solution doesn't look so different from the virtio-dmabuf [5] approach > proposed by Gerd a few months back, it's just extended to be a global > VFD <-> FD registry instead of a dmabuf <-> unique-handle one. One > great thing about this approach is that we can re-use it for any kind > of FD sharing, not just dmabufs. A dedicated is most likely not going to happen. Probably virtio-gpu and possibly other devices too will support attaching a unique handle (a uuid probably) to a dma-buf, then share buffers like this: (1) guest userspace export virtio-gpu resource as dma-buf (2) guest kernel generates uuid, sends uuid to the host (or maybe we let the host generate the uuid, not clear yet), attaches it to the (guest) dma-buf. (3) guest userspace imports the dma-buf into virtio-vdev (4) virtio-vdec driver finds the uuid attached to the buffer and passes it on to the host, (5) virtio-vdev device can use the uuid to lookup the buffer on the host, then have the host decoder send the data directly to the host gpu ... It certainly makes sense to use this for wayland too, so you just pass around the uuid if you want pass around a dma-buf (no matter which of the three solutions). > #2 is a bit challenging, since it requires the proxy to know about all > possible kind of FDs and do a FD <-> unique handle conversion with some > help from the subsystem backing the FD. For dmabufs, that means we > need to know who created the dmabuf, or assume that only one device is > used for all allocations (virtio-gpu?). See above, the uuid idea should simplify this. > #3 is pretty similar to #1 in its design except that, instead of using > the VSOCK infrastructure it's using a new type of virtio device. I > guess it has the same pros and cons #1 has, and the name should probably > be changed to reflect the fact that it can transmit any kind of data not > just wayland. Even though vsock looks simple at first it isn't when you look at the details. You'll want support more streams than virtqueues. So you'll go multiplex. You want good performance, but you also don't want allow streams to DoS the device by filling up the queue. Thats why I don't like the new virtio device idea much and would prefer vhost being reused, either directly (#1) or via proxy (#2). Note that vhost aims to be hypervisor-agnostic and we have (unless I missed something) three transports for it: virtio, vmware and hyperv. So extending that with virtio-only features might not be the best idea. 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. Final note: We have a new kid on the block: virtio-fs. I think virtio-fs with dax enabled should allow for shared file mappings between host and guest. That is something a proxy (#2) might be able to make use of. cheers, Gerd - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)
> FD <-> VFD mappings would have to be created > by the subsystem in charge of the object backing the FD (virtio-gpu for > exported GEM buffers, virtio-vdec for video buffers, vsock for unix > sockets if we decide to bridge unix and vsock sockets to make it > transparent, ...). The FD <-> VFD mapping would also have to be created > on the host side, probably by the virtio device implementation > (virglrenderer for GEM bufs for instance), which means host and guest > need a way to inform the other end that a new FD <-> VFD mapping has > been created so the other end can create a similar mapping (I guess this > requires extra device-specific commands to work). My recent proposal for cross device resource sharing seems like it could be relevant here: https://markmail.org/thread/jsaoqy7phrqdcpqu. -David - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
