Very different: Linux running in a virtual machine can't bind mount into a macOS host's filesystem. So they use virtiofs.

▲

miohtama 5 days ago | parent | next [-]

MacOS container filesystem/IO has been bog slow preventing even some basic dev container use cases. Hopefully this will fix the issue.

▲

jdub 5 days ago | parent [-]

It's not substantially different from previous approaches (9pfs vs. virtiofs).

My suggestion: Don't use the host filesystem from the guest at all. It'll be faster, and better isolated. It's a false convenience.

▲

AtlasBarfed 5 days ago | parent [-]

sshfs?

	▲	jdub 4 days ago \| parent [-]
		That's a less efficient protocol than 9pfs and virtiofs, even if you subtract the encryption. An example of improving efficiency: virtiofs has a relatively recent feature to map pages from host memory directly into guest memory, but that's a lot of risky acrobatics if your priorities are reliability and isolation... ... but it's not supported by Virtualization Framework's built-in virtiofs "folder sharing". (sad face) ... but someone could build it on top of the new macos 27+ custom virtio device support. (intrigued face)

▲

lxgr 5 days ago | parent | prev [-]

This applies to both containers and container machines though, right?

▲

jdub 5 days ago | parent [-]

Containers (those popularised on Linux by Docker) are built on Linux primitives like cgroups and namespaces, so they're running directly on the same kernel, same VFS, often the same FS, etc. Their isolation properties rely on (a) all those Linux features working as expected, and (b) the container runtime setting them up properly.

Depending on your threat model, that's fine, but a lot of people (including me) will say that containers are not a security mechanism.

But macOS requires[1] virtualisation for containers anyway; the security is just a bonus.

[1] at least for a real Linux kernel...

▲

lxgr 5 days ago | parent [-]

The surface of an OS is definitely larger than that of many hypervisors, which is e.g. why browsers often provide their own much narrower sandbox.

On the other hand, in other scenarios, people trust the security boundaries of their working as expected all the time, no? This is the basis of e.g. Android app isolation (every app runs under its own Linux UID/GID), and true multi-user Unix systems trusting the OS's security boundaries to hold have decades of history.

▲

jdub 5 days ago | parent [-]

Different threat models. Your typical Android device (and Linux server for that matter, at home or at scale) is not usually running security-sensitive general workloads for multiple tenants in the same OS instance. :-)

▲

fc417fc802 5 days ago | parent [-]

I don't think that's right. The threat model for Android for example could well be a malicious third party leveraging a vulnerable app to gain access to your banking app on the same device. There's definitely (meant to be) a security boundary between apps.

	▲	jdub 5 days ago \| parent [-]
		These are all security boundaries of a kind, some more effective than others, balancing priorities according to threat model. Running every app on your phone in a hardware virtual machine would be... an expensive choice.