RE: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host

[Shi, Guohuai]

> -----Original Message-----
> From: Christian Schoenebeck <qemu_oss@crudebyte.com>
> Sent: 2022年4月14日 19:24
> To: qemu-devel@nongnu.org; Shi, Guohuai <Guohuai.Shi@windriver.com>
> Cc: Bin Meng <bmeng.cn@gmail.com>; Greg Kurz <groug@kaod.org>
> Subject: Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host
> 
> [Please note: This e-mail is from an EXTERNAL e-mail address]
> 
> On Mittwoch, 13. April 2022 05:30:57 CEST Shi, Guohuai wrote:
> > > We have 3 fs drivers: local, synth, proxy. I don't mind about proxy,
> > > it is in  bad shape and we will probably deprecate it in near future 
> > > anyway.
> > > But it would be good to have support for the synth driver, because
> > > we are using it for running test cases and fuzzing tests (QA).
> >
> > synth driver can not be built on Windows platform (or cross build on
> > Linux). So the test cases can not work on Windows.
> 
> Could you please be more specific what kind of challenge you see for making 
> the
> synth driver working on Windows? The synth driver is just a simple mockup 
> driver
> [1] that simulates in-RAM-only a filesystem with a bunch of hard coded dirs 
> and
> files, solely for the purpose to run test cases. So the synth driver does not 
> interact
> with any real filesystem on host at all. My expectation therefore would be 
> that
> it just needs to tweak some header includes and maybe declaring missing POSIX 
> data
> types, which you have done for the local driver already anyway.
> 

For 9p-synth:

I had enabled 9p-synth.c and built it successfully on Windows platform.
However, test cases code are not built on Windows host.
So I think it is useless that enable synth on Windows host (no way to run it).

> BTW support for macOS hosts has just been recently added for 9p, I know it is
> different as its a POSIX OS, but maybe you might still find the diff [2] 
> helpful.
> 
> [1] https://wiki.qemu.org/Documentation/9p#9p_Filesystem_Drivers
> [2] https://gitlab.com/qemu-project/qemu/-/commit/f45cc81911adc772
> 
> > > What are the limitations against security_model=mapped on Windows?
> > > Keep in  mind that with security_model=none you are very limited in
> > > what you can do with 9p.
> >
> > MSYS library does not support extend attribute (e.g. getxattr), And
> > does not support POSIX permission APIs (e.g. chmod, chown).
> > Security model is useless on Windows host.
> 
> That would be security_model=passthrough, yes, that's not possible with msys.
> The recommended way in practice though is using security_model=mapped [3] for 
> all
> systems, which should be possible to achieve with msys as well ...
> 
> [3] https://wiki.qemu.org/Documentation/9psetup#Starting_the_Guest_directly
> 
> > It is possible that to "map" extend attribute to NTFS stream data.
> > However, if Windows host media is not NTFS (e.g. FAT) which does not
> > support stream data, then the "map" can not work.
> 
> ... yes exactly, it would make sense to use ADS [4] instead of xattr on 
> Windows.
> ADS are available with NTFS and ReFS and maybe also with exFAT nowadays (?), 
> not
> sure about the latter though. But I think it is fair enough to assume Windows 
> users
> to either use NTFS or ReFS. And if they don't, you can still call 
> error_report_once()
> to make user aware that
> seucrity_model=mapped(-xattr) requires a fileystem on Windows that supports 
> ADS.
> 
> [4] https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(ADS)
> 

Windows does not support POSIX permission. 
So I think that only allow user to use security_model=none is reasonable on 
Windows host.

There is a difficulty to support "mapped" or "mapped-file" on Windows host:
There are many functions in 9p-code using APIs like "openat", "mkdirat", etc.
MSYS does not support that (openat is not valid on Windows host).
I remember that 9p replaced "open" by "openat" for a long time.
To fully support "security_model=mapped", 9p for Windows need to replace 
"openat" by "open".
This may impact too many functions.

I would have a try to enable "mapped" by using ADS, but it looks like a big 
refactor for 9p-local.c

Best Regards,
Guohuai