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