Re: [Qemu-devel] [PATCH v4 3/5] 9p: Added virtfs option "remap_inodes"

[Greg Kurz]

On Sat, 29 Jun 2019 12:20:49 +0200
Christian Schoenebeck <address@hidden> wrote:

> On Freitag, 28. Juni 2019 16:23:08 CEST Greg Kurz wrote:
> > > > This feature applies to all backends IIUC. We don't really care for the
> > > > synth backend since it generates non-colliding inode numbers by design,
> > > > but the proxy backend has the same issue as local. So...
> > > 
> > > Yeah, I was not sure about these, because I did not even know what these
> > > two were for exactly. :)  [ lazyness disclaimer end]
> > 
> > "proxy" is a backend where all I/O accesses are performed by a separate
> > process running the virtfs-proxy-helper command. It runs with root
> > privileges, which provides the same level of functionality as "local"
> > with security_model=passthrough. It also chroot() into the shared
> > folder for extra security. But it is slower since it all requests
> > still go through the virtio-9p device in QEMU. This would call
> > for a vhost-9p implementation, but it's yet another story.
> > 
> > "synth" is a software pseudo-backend, currently used to test 9pfs
> > with QTest (see tests/virtio-9p-test.c).
> 
> Thanks for the clarification!
> 
> So the proxy backend sounds like an idea that has not been implemented fully 
> to its end. I guess it is not really used in production environments, right? 

I don't have any feedback unfortunately... The biggest problem with proxy is
likely it's poor performance : every request needs to go through many hops.

guest->QEMU->proxy->QEMU->guest 

> What is the actual motivation for this proxy backend?
> 

The motivation is security: only the proxy helper runs with privileges (we
generally don't want to run QEMU as root), the helper can chroot() and thus
prevent the guest to access anything outside the shared folder.

> And now that I look at it, I am a bit surprised that there is this pure Unix 
> pipe socket based proxy variant, but no TCPIP network socket variant. I mean 

The Unix socket is required in order to pass open file descriptors between
QEMU and the proxy, using SCM_RIGHTS ancillary messages. There's no such
thing with TCPIP sockets.

> the latter is AFAIK the original idea behind the 9p protocol and IMO might be 
> interesting to physical separate pure storage backends that way.
> 

The right thing to do would be to have the "proxy" process to directly
access the rings of the virtio-9p device (ie, vhost), so that requests
only go through:

guest->proxy->guest

> Best regards,
> Christian Schoenebeck