On Thu, Nov 16, 2017 at 3:51 PM, Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: >> > > I thought of SCM_RIGHTS on AF_VSOCK, which would return BADF if a FD is >> > > passed that cannot be shared in the requested direction. Are there any >> > > better options? >> > >> > When limiting this SCM_RIGHTS support to dma-bufs, guest -> host, that >> > could actually work. >> >> Would you go with SCM_RIGHTS as defined for AF_UNIX, or with a different, >> more specific name? > > Hmm, good question. Maybe a separate name is less confusing. > >> > The nice thing about dma-bufs is that the size is >> > fixed and the pages are pinned. >> >> Those pages are permanently pinned? Would have expected to be only pinned >> while scanning out, and such. > > Hmm, not fully sure, maybe only when someone holds a reference. > Didn't look at them too deeply from the kernel side. >From a AF_VSOCK perspective there are two things that worry me: 1. Denial of Service. A mechanism that involves pinning and relies on guest cooperation needs to be careful to prevent buggy or malicious guests from hogging resources that the host cannot reclaim. Imagine a process on the host is about to access the shared memory and the guest resets its virtio-vsock device or terminates. What happens now? Does the host process get a SIGBUS upon memory access? That would be bad for the host process. On the other hand, the host process shouldn't be able to hang the guest either by keeping the dma-buf alive. 2. dma-buf passing only works in the guest->host direction. It doesn't work host<->host or guest<->guest (if we decide to support it in the future) because a guest cannot "see" memory ranges from the host or other guests. I don't like this asymmetry but I guess we could live with it. I wonder if it would be cleaner to extend virtio-gpu for this use case instead of trying to pass buffers over AF_VSOCK. Stefan
