Support for fuse_custom_io feature

[legezywzh]

Libfuse C language library supports the fuse_custom_io feature initially in below commit: https://github.com/libfuse/libfuse/commit/50c74e645928affa1af6e9a5a6ea6a3b9d3c52dc

Traditionally fuse filesystem servers read fuse requests and write fuse responses by /dev/fuse character device, but in the case of virtiofs, fuse requests come from guest os, fuse filesystem servers run in host os, so /dev/fuse won't work here.

Many popular fuse filesystems based on go-fuse library, in the case of qemu virtiofs or dpu virtiofs, by fuse_custom_io feature, user can implement application-defined I/O functions to fetch and reply fuse requests. then we can let these fuse filesystems based on go-fuse deploied on host running qumu or dpu easily with least modifications.

Could the go-fuse community plan to support this fuse_custom_io feature(backport above patch)? Thanks in advance, for me, currently I did't write any go codes yet.

[hanwen]

this is the first time I hear of this. Some notes to myself:

• similar in scope to NFS, but don´t need to support multiple simultaneous clients and can use shared memory for improved efficiency.
• design: https://virtio-fs.gitlab.io/design.html
• FUSE is called by virtiofsd
• the FS cannot trust the incoming requests, as the guest OS is untrusted.

Open questions:

• how can one test this?
• how "untrusted" is the guest OS? The FUSE library implicitly assumes not only that requests are well-formed but also that the VFS lookups are sane. Can the guest OS trick the FS into creating a circular inode graph for example?

[legezywzh]

this is the first time I hear of this. Some notes to myself:

• similar in scope to NFS, but don´t need to support multiple simultaneous clients and can use shared memory for improved efficiency.
• design: https://virtio-fs.gitlab.io/design.html
• FUSE is called by virtiofsd
• the FS cannot trust the incoming requests, as the guest OS is untrusted.

Open questions:

• how can one test this?

There is a simple test case in libfuse and it justs transmits FUSE_INIT message on application-defined I/O functions, which is unix socket here, other than /dev/fuse. https://github.com/libfuse/libfuse/blob/master/example/hello_ll_uds.c https://github.com/libfuse/libfuse/blob/master/test/test_custom_io.py

For myself, I also think it's hard to have a full test with normal tools on hand, but it's a useful feature in certain cases. Currently I used it in dpu, dpu can help to offload virtiofsd or filesystem server from host machine to dpu，in this case，host machine and dpu runs different os, softwares on dpu will fetch vritio-fs reqeusts from dpu hardware, and use fuse_custom_io to define I/O functions, then we can use these I/O functions to interactive with filesystem server based on libfuse。

• how "untrusted" is the guest OS? The FUSE library implicitly assumes not only that requests are well-formed but also that the VFS lookups are sane. Can the guest OS trick the FS into creating a circular inode graph for example?

I'm not sure, virtio-fs is widely used, seems that it doest not require the guest os is trusted.