Qubes outsourcing/recruitment of computational power

I might be chatting absolute shit here, but if you’ve got a qubes machine, and another truly, completely airgapped machine, is it possible or even advisable to try to recruit the processing power of another computer you own and trust (offline, risks mitigated) to work on specified processes?

I don’t know what I’m imagining here. I don’t mean copying from one computer to another. I mean, like a hive mind. I’m just looking to the future.

Is that sort of what qubes air is about?

Yes this is exactly what Qubes Air is about.

The link: Qubes Air: Generalizing the Qubes Architecture | Qubes OS.

1 Like

Does this basically mean instead of hardware, we will (have to) trust to cloud and browsers?

No. You will be able to use your other devices as qubes.

1 Like

Yes, that is clear from the diagrams for different models. What confuses me, dom0 isn’t mentioned anywhere, and since I’m by default “airgapped” from the cloud-likes, it is obvious why I can’t perceive where the dom0 should be, or it will be deprecated…?

How can you manage your qubes without some entity which has control over them? What do you mean by “airgapped”? You need a connection to manage them.
I guess you will have to choose where dom0 is.

Now I’m even more confused my simple question “where the dom0 should be” was answered by - a question:

But I’ll answer to it first anyway:
The Admin API solves this problem elegantly without requiring network access to dom0, and we show exactly how below.”
which is again obvious from the mentioned diagrams, too.

All this hoping I will get an answer to a simple question: where will dom0 be in QubesAir, or will it exist at all?

I wanted, hopefully in a funny way, to say that I’m running away from clouds. Local, free, paid, any. Sorry it wasn’t obvious, just forget the remark. I am aware, again from the diagrams that connections are planned via qrexec and (oh God) TCP/IP, so it wasn’t my question too.

Only one question that confuses me.

I also carefully read the other topic, but no one mentioned dom0 even there, and that is why I’m asking about it here - so this shouldn’t be considered as “talking about already spoken”

dom0 = Admin VM as stated here:

Admin VM (i.e. dom0)

1 Like

Any device, even the ones with new hardware?

I don’t know the details of the implementation. It’s not even implemented yet AFAIK. I guess if it can run a supported hypervisor via network, it should work?

I don’t see what’s wrong with an isolated, remote or local device under control of a chosen dom0. It further expands the Qubes approach of compartmentalization. For example, if another device runs a different CPU architecture, it may not be vulnerable to the same attacks (e.g. Spectre/Meltdown).

See also: Qubes-Air? Qubes in the cloud?.

Yes. Also, Qubes further compartmentalizes the system by separating dom0 into sys-gui, admin VM, sys-audio. At the end we can expect that dom0 will run something super-minimal. Also, dom0 is the term coming from Xen and it will not be appropriate anymore in a distributed system.