
QEMU: virtfs permits guest to access entire host filesystem - remx
https://bugs.chromium.org/p/project-zero/issues/detail?id=1035&can=6&q=
======
devicenull
The v9fs code has been a _major_ source of bugs. Hopefully no one's using that
in production...

[https://www.cvedetails.com/vulnerability-
list.php?vendor_id=...](https://www.cvedetails.com/vulnerability-
list.php?vendor_id=7506&product_id=&version_id=&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=1&trc=159&sha=6055b0330a499f6aed7620adb79dc0cc143e50bc)

~~~
problems
I think most people when running in production wind up using network based
protocols instead, NFS, SMB, etc which are much more security and time tested.

I've never heard of anyone using this kind of thing outside of personal VMs or
development.

~~~
koverstreet
v9fs has some major advantages - the protocol is much simpler and more
lightweight, which makes accelerating it over virtio much more tractable and
effective. And it's nicely integrated into qemu so you don't need to bother
with setting up a server.

Really, it's not competing with NFS/SMB, it's just aimed at fast passthrough
for local filesystems.

However, having read a decent amount of the code myself, it is pretty
crappy/sketchy.

However, it's not a lot of code and the basic idea is sound and the protocol
is simple and well designed, it really wouldn't take someone with the right
skills long to rototill it and make some drastic improvements (there's
performance gains to be had in there, too).

~~~
sitkack
Couldn't one start by linking a scrubbing bridge for the protocol in Rust and
grow from there?

~~~
pm215
I'd like to be able to use Rust in QEMU one day, but just at the moment it
doesn't support all the platforms QEMU does. The sheer range supported by a
standard GCC C toolchain is very hard for a new language to catch up to.

(It mostly has support for the CPUs we support and for the OSes but not always
in all combinations, eg no ARM FreeBSD support. It also sometimes doesn't
support the range of OS versions we do, eg no OSX 10.6 support, no support for
Windows before Windows 7. And some things are only in Rust's tier 3, like
OpenBSD support. We'd also need to dump some of the "probably nobody's using
this really" older platform support code, like ia64 or Solaris.)

Oh, and Rust would need to be in the stable/LTS releases of distros before we
could use it. That's going to take time to percolate through.

~~~
geofft
I'd imagine the way you'd use Rust for the use case described is to have it be
a library for certain protocol implementations, and leave the bulk of the
application in C. Then you use very little of the standard library, and you
don't call the platform APIs directly from Rust. Over many years you might
port all of QEMU eventually, but over many years Rust platform support will
improve too.

For things like ARM FreeBSD support, given that Rust already supports ARM non-
FreeBSD and FreeBSD non-ARM, I think the blockers are likely to be random
#defines for system calls (unless the FreeBSD folks are using a different
userspace ABI on ARM than, e.g., Linux on ARM). Those are interesting if your
goal is to reimplement QEMU in Rust, but they're not interesting if your goal
is to reimplement the 9P protocol in Rust.

It looks like Windows XP is pretty well supported, and the primary reason it
doesn't have official support is that the OS itself is out of support? (You
can also take sitkack's suggestion of just not enabling the security-focused
code on a no-longer-security-supported OS.) Rust's standard library doesn't
work on OS X 10.6 because of a change in TLS / threading models in 10.7, but
again, if Rust isn't opening threads or allocating memory and is leaving that
all to C, you don't care.

Does the QEMU project treat OpenBSD, ia64, and Solaris as effectively more
supported than what Rust calls tier 3? Do you do automatic builds on those
platforms? If I report a bug that shows up only on those platforms, are
developers likely to have access to such systems to reproduce them? If not,
having a tier 3 build of QEMU depend on a tier 3 build of Rust seems totally
fine.

~~~
steveklabnik
> It looks like Windows XP is pretty well supported, and the primary reason it
> doesn't have official support is that the OS itself is out of support?

Yes, this is accurate. It's a "best effort" kind of thing; the OS doesn't have
certain primitives that would be needed for a full implementation of libstd;
IIRC concurrency primitives are the main culprit?

------
sofaofthedamned
Virtfs is a cluster fuck. Using rsync over it creates hundreds of thousands of
file handles that never close. Reported to Ubuntu months ago, nothing fixed.
Red Hat had the better idea of going nowhere near it. Canonical produce so
much shovelware that they don't support, I won't get bit by this again.

[https://bugs.launchpad.net/qemu/+bug/1336794](https://bugs.launchpad.net/qemu/+bug/1336794)

------
als0
Yet another example where SELinux could have mitigated this effect.

~~~
rwmj
Anyone using qemu has disabled 9p for a really long time.

~~~
chrisper
How do I disable it or is it disabled by default?

~~~
bonzini
It is a device that you have to add explicitly to the virtual machine.

------
gbrown_
Semi hopping on the QEMU bashing train but recall Google ripped it out for
GCE.

[https://cloudplatform.googleblog.com/2017/01/7-ways-we-
harde...](https://cloudplatform.googleblog.com/2017/01/7-ways-we-harden-our-
KVM-hypervisor-at-Google-Cloud-security-in-plaintext.html)

~~~
theamk
Well, Google rightfully said that GCE does not need most QEMU features, so
they have made a simplified version. Is is sad they did not release it.

On the other hand, there are people who need QEMU features: we have a QEMU-
based test script for boot images which actually uses a few more exotic
features to simulate the target environment.

~~~
sphix
The Google version is supposedly coupled heavily to their infrastructure and
therefore would give little benefit to opensource without also open sourcing a
large portion of their infrastructure.

~~~
kuschku
> without also open sourcing a large portion of their infrastructure.

Well, that’d not necessarily be bad for the dev community.

------
codebeaker
From the title I understood this was a feature that had arrived in QEMU, seems
like it could have it's place on development machines/etc where the only
reason you're using a VM is to get access to some alt. architecture.

------
Endy
Um, silly question. Does this affect people using QEMU to run ReactOS,
FreeDOS, and their proprietary counterparts to play old games and use old
programs that don't work as well in DOSBox?

~~~
bonzini
Neither ReactOS nor FreeDOS nor their proprietary counterparts have drivers
for virtio-9p, so most likely you are not using the device and are not
vulnerable.

~~~
Endy
9p as in Plan 9 from Bell Labs? I only use that from LiveCD - and mostly as a
goof and a basic test for a machine.

------
f2f
well then, plan9 finally becomes useful for something!

