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

[Christian Schoenebeck]

On Donnerstag, 14. April 2022 19:25:04 CEST Shi, Guohuai wrote:
> > -----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).
[...]
> 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).

Please, don't give up too soon. Looking at tests/qtest/meson.build it starts 
with:

# All QTests for now are POSIX-only, but the dependencies are
# really in libqtest, not in the testcases themselves.
if not config_host.has_key('CONFIG_POSIX')
  subdir_done()
endif

And looking at tests/qtest/libqtest.c I "think" this should be working on 
Windows as well. It uses socket APIs which are available on Windows. I don't 
see a real show stopper here for Windows.

Could you please try if you can compile the tests on Windows? What we would 
need is test/qtest/qos-test, we don't need all the other tests:

https://wiki.qemu.org/Documentation/9p#Test_Cases

> > > 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.

It depends on the use case. I assume your use case are Windows guests, in that 
case you don't have the concept of POSIX permissions neither on guest side, 
nor on host side (on the long-term I am pretty sure though that Windows guest 
users would want to have some kind of Windows ACL mapping implementation as 
well).

> 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

Regarding openat(): We had a similar challenge for macOS host implementation; 
macOS does not have mknodat(), so what we're currently doing is

  pthread_fchdir_np(...)
  mknod(...)

  https://github.com/qemu/qemu/blob/master/hw/9pfs/9p-util-darwin.c#L84

So on Windows you could do:

  chdir(...)
  open(...)

as workaround for providing openat() for msys.

For security_model=mapped(-xattr) to work on Windows you basically would need 
to provide a replacement implementation (based on Windows ADS) in
9p-util-windows.c for:

  ssize_t fgetxattrat_nofollow(int dirfd, const char *filename, const char   
                               *name, void *value, size_t size);

  ssize_t flistxattrat_nofollow(int dirfd, const char *filename,
                                char *list, size_t size);

  ssize_t fremovexattrat_nofollow(int dirfd, const char *filename,
                                  const char *name);

  int fsetxattrat_nofollow(int dirfd, const char *filename, const char *name,
                           void *value, size_t size, int flags);

So it does not look too bad I think to get security_model=mapped working, and 
it would make Windows 9p host support much more usable (for Linux guests, 
macOS guests, but also for Windows guests with mapped Windows ACL in future).

Best regards,
Christian Schoenebeck