It did not help Plan 9 to conquer the world.

I found a good introduction to Plan 9 architecture in this comment:

https://news.ycombinator.com/item?id=15989697#15990077

Why would you want something like that though? What are the benefits that are worth the huge amount of overhead of having to pass through the internet to connect components?

I mean I get cloud computing and such, but this seems to be aimed as a consumer OS, which is very sensitive to delays and whatnot.

One reason: the prospect of an endless stream of unpatchable Spectre-like hardware vulnerabilities.

The "real problem" exposed by Meltdown and Spectre is running untrusted software on the same hardware where sensitive information resides. Moving away from physical coupling defends against potential sidechannel attacks.

The Qubes approach of "careful decomposition of various workflows, devices, apps across securely compartmentalized containers" seems to point a way forward after this sobering assessment:

http://robert.ocallahan.org/2018/01/long-term-consequences-o...

> The "real problem" exposed by Meltdown and Spectre is running untrusted software on the same hardware where sensitive information resides.

Well obviously. Which is why people try to avoid that as much as they can when they are handling actually sensitive information.

> Moving away from physical coupling defends against potential sidechannel attacks.

... is a correct deduction, but using cloud VMs hardly qualifies as following the principle (except if they are only used for lowest-privilege stuff, but even then, the system now requires connectivity). Now you don't know who else is on your hardware, and you don't even control the hardware in the first place.

Qubes aims to provide both consumer and enterprise workflows, and everything in between. People use computers for all sorts of things. A full Qubes system delivered to a tablet/phone interface is also a fine tradeoff for millisecond GUI delays.

Passing through GPUs is problematic, as it's a massive attack surface.

Could you elaborate on the 'massive'? Let's say you let the VM see the GPU. What kind of attack would that enable? Let's suppose that a virus inside VM manipulates GPU outside of what applications are allowed to do. What worst thing could happen?

The GPU is a PCIe/AGP "bus master", so it can usually initiate DMA transfers from host memory and read anything it likes. IOMMU blocks some of this, but is not a perfect defence. https://security.stackexchange.com/questions/150386/does-iom...

Thanks, according to [1], it seems DMA is quite a 'backdoor', bypassing any memory management the kernel would do. But it is not clear to me whether this allows the attacker inside VM also to write into the forbidden regions of memory and thus either modify behaviour of the hypervisor or send information out via Internet.

[1] https://en.wikipedia.org/wiki/DMA_attack

GPUs can definitely write to host memory. In some situations, this is the only way to the results of some operations that the GPU performed (e.g. grab framebuffer for screenshots or video recordings). Usually, it's the job of the driver to check for illegal copy target addresses.

The primary objective would be exfiltration, executive control is only secondary. If you can exfiltrate keys or hashes then you might not even need to use DMA to gain access to a system.

It's unavoidable for me.

It provides no drawback for users who don't utilize it, and the alternative is me remaining with KVM which is a vastly larger attack surface, so your argument defeats itself.

> The idea of having an "operating system" made up of components dispersed across the globe seems like a fantasy that is too good to be true.

Read up on Amoeba and Sprite in the 80's.