How exactly is dom0 made network-less?

General Discussion
1

Hi,

Repeating my question from another thread in a separate one:

How exactly is dom0 made network-less?

1 Like
2

the basic Qubes OS architecture should answer this question:

The key ‘features’:

- Networking code sand-boxed in an unprivileged VM (using IOMMU/VT-d)

- No networking code in the privileged domain (dom0)

These together makes the dom0 ‘networkless’ in practice.

And most importantly: how it is compare to other virtualisation solutions:

  • KVM on Linux: there is a full Linux distribution acting as a host OS, and handling ALL of the network traffic of your VMs (by default)
  • ESXi: there is a dedicated management interface, which can be (and should be) separated from the VM traffic. However those are merged to a single physical interface by default.
  • XPC-ng: all of the networking stack is runnin in dom0 (by default)
  • Hyper-V: there is a full windows core acting as a hypervisor, similar to how KVM works on Linux.
3

It simply doesn’t have a NetVM. Updating dom0 is then handled through the configured UpdateVM.

4

No, it is not the case.

You can’t even add a NetVM to dom0 without heavily modifying the basic Qubes OS architecture de sign.

See above in the linked architecture design

Updating the networkless dom0 is handled by:

1 Like
5

But that simply says that another VM (not dom0) is networked, i.e. that doesn’t answer why dom0 has no net.

- No networking code in the privileged domain (dom0)

What does this mean exactly? If it means that no networking packages have been installed and installing them in dom0 will make dom0 networked, that doesn’t seem to be the case.

My OP question is what exactly has been done to make dom0 impossible to connect to network.

6

This is where qrexec is to be studied and the forum is full of such resources too/

7

With dracut modules in initramfs. Look at /usr/lib/dracut/modules.d/90qubes-pciback/module-setup.sh and /usr/lib/dracut/dracut.conf.d/30-qubes.conf. The settings disable to load any network pci … device.

To enable network look at my link in the old thread, what has to be done in dom0 to enable network.

1 Like
8

qrexec is not involved, as far as i know.

9

All the communication is made via qrexec, no network stack, so I am not sure how it is not involved?

10

intern communication is over qrexec, extern communication (network) is over pci network device. @qubist asked about that.

1 Like
11

The Qubes installer attaches all network class controllers to sys-net and all USB controllers to sys-usb by default, if you chose to create the network and USB qube during
install. While this covers most use cases, there are some occasions when
you may want to manually attach one NIC to sys-net and another to a custom NetVM, or have some other type of PCI controller you want to manually attach.

The default is achieved by Xen’s dedicated (backend) driver domains routing via virtual interfaces:

1 Like
12

I am trying now to genuinely understand. What do you mean by “intern” and “extern” communication. Some example would be the fastest way for me to comprehend.

13

It’s in the docs:

1 Like
14

extern==internet is normal over sys-net.

@qubist asked this:

What does this mean exactly? If it means that no networking packages have been installed and installing them in dom0 will make dom0 networked, that doesn’t seem to be the case.

My OP question is what exactly has been done to make dom0 impossible to connect to network.

15

Thanks, but I don’t see how extern==internet communication is involved in this topic at all.

qrexec is the basics that enables communication from dom0 to and between domains. You make RPC calls with qrexec. I even use qrexec instead internet to install temp packages in non-networked dispVMs (even in sys-firewall or sys-net regardless of them being networked, so I could get packages from cacher when they exist, or not, for the anonymity purpose) for the sake of tests or other legit reasons, in order to keep its top templateVM free of larger attack surface

Editing network stack is how dom0 was made networkless. That is the answer on this topic’s subject.

16

cat /usr/lib/dracut/modules.d/90qubes-pciback/module-setup.sh

#!/usr/bin/bash

This is a Qubes-specific dracut module that takes care of detecting and

hiding all networking devices (and optionally USB devices) at boot time so

that Dom0 doesn’t load drivers for them…

1 Like
17

Loading drivers is not enough. Hiding them serves primarily in order network controllers to be able to be passed to sys-net.

You’d still have to heavily, as @Zrubi pointed out, edit network stack to be able to network dom0

18

what do you mean by edit network stack?

19

NetorkManager, systemd-netwrkd, for example. I don’t know exact places and how, because why should I know something I don’t need to know.

Asking questions like this topic’s OP is the worst ones someone can afford to themselves. I don’t see they serve to anything else but satisfying curiosity, thus wasting of time

As I said on other topic: such a framing looks like a duck flying with its butt ahead - it knows where it’s coming from, but it doesn’t know where it is flying to/through.

What any but basic knowledge of how dom0 is netwrokless helps to? On the contrary, understanding qrexec helps - that is flying with a head ahead. But I am aware that mind state is hard to change.

20

you mean edit==installing Networkmanager or systemd-networkd.

Because qrexec is not involved here.

I have network in dom0 and all I did is editing dracut config and installing systemd-networkd.
This was the question from OP.

1 Like