IIUC, it describes how to install Xen on bare metal, using Debian for dom0.
But that document describes doing it from scratch at a GRUB command line. It doesnât describe how to convert the dom0 OS from Fedora to Alpine, for example, using Qubes manager, or using dom0.
It would be great if you could execute a commend that changes the .iso
I simply shared information which I found.
The point is - obviously Debian is a possible option.
FWIW, I tried removing individual firmware packages in a Fedora 38 qube. It works fine and e.g. removing nvidia-gpu-firmware does not ask to remove linux-firmware itself. It is also possible to remove other individual firmware packages. So, obviously in newer Fedora versions (newer than those in dom0) some work in that direction has been done.
Re. Alpine - I have never used it. I have only read it is minimalist.
That said, I agree with the devs that before having a working GUI domain, minimizing the rest of the distro of dom0 is probably a useless exercise, as the end result would still be a too big dom0.
As a whole, it might be a good idea to see some collaboration between the guys from suckless.org and the Qubes team, and hopefully have a suckless dom0 
1 Like
I guess my question really is, how are dom0 and Fedora integrated?
I guess the answer you are looking for might be: they arenât. Dom0 is based on Fedora and the devs added some 2.5k lines of their code at the beginning of Qubes, the way Whonix/Kicksecure are based on Debian and customized by their devs in different ways.
So dom0 is like a hybrid between Fedora and Xen. So Fedora and Xen had an offspring.
No. Nothing of Xen is in dom0. Look at the picture above. Only Fedora is in dom0.
All the hardware has drivers in dom0 (in terms of Xen, not Qubes). Dom0 instructs Xen to start and stop VMs. To do that, among other things, Xen uses drivers from dom0 to access the hardware.
So no part of the Xen API is in dom0. Does this mean that dom0 is made up only of Fedora?
What did you read and conclude?
so the hardware drivers are isolated in dom0, which uses Fedora.
To clarify the relationship between dom0/Xen/Fedora:
Xen is the underlying software that has complete control over the machine. To compare this to a more typical situation, if you had installed Debian normally and then opened a Fedora VM in VirtualBox, then Xen would be analogous to the Debian installation and dom0 would be analogous to Fedora (there are technical differences between using Xen and VirtualBox which are important in many circumstances, but this is roughly correct at a high level).
dom0 is âjustâ a virtual machine like every qube on the system. The reason that it is treated specially is that Xen decides to give dom0 high privileges in order to maintain the environment. Organizing it this way helps keep Xenâs attack surface small (admittedly this is achieved in part by offloading the risk onto dom0, which has its own attack surface as is obvious from this thread). So dom0 âincludes the Xen APIâ in the sense that it uses the Xen API, but it does not implement it. However, it does implement tools like qrexec which QubesOS relies on for secure communication.
dom0 manages hardware drivers by default, but this can be delegated to other VMs. For example, in QubesOS the USB driver runs in sys-usb and the network driver runs in sys-net. This is particularly useful for those drivers because they are an easily accessible attack vector (any USB device you plug into your computer or any computer on the internet you talk to can attack them). By isolating them, an attacker who compromises your network driver cannot then read data directly off of a USB drive.
And finally one note on networking tools in dom0 - while it does not access the external network, networking tools might be useful for internal communication as well. For example, one way to bind a service listening on a port to qrexec for internal communication is to use socat which is a networking tool. In an ideal world we would not need to use networking protocols at all for internal communication and everything would use the tools that QubesOS supplies, which are technically sufficient, but this requires a large amount of work and so either a large number of developers or a long time (this caveat also applies to the desire to minimize dom0, which I agree is a good objective in principle).
2 Likes
Fedora is used as the Xenâs Linux kernel for dom0 it seems.
So itâs essentially a matter of, which Linux distro has the most secure Xen kernel.
And is there a way to diff the Xen kernels of different Linux distros.
Is there anyplace to find the source for the Xen kernels of all these different distros and compare them?
There are 2 separate things here: Xen itself and dom0. Xen itself does not contain Fedoraâs software, although it is produced by the same build system used by Fedora and there is a package definition for Xen maintained in Fedora. In practice, a compromise in either Xen or dom0 gives an attacker complete control over the system (if they only have user-level privileges in dom0 what they can do is somewhat limited, but I would still scrap the installation completely if I discovered that level of intrusion; I assume they could at a minimum capture a screen recording and send it to a remote machine).
You can find the Xen package definition that QubesOS uses and extra patches it applies in this GitHub repository. According to the notes in xen.spec.in, security-related patches follow the naming convention Patch05##, where the pound signs are replaced with digits. You can find the upstream source from the Xen Project website. If you want to compare the modifications that are made in QubesOS to other distros then you will need to look at the package definitions for the other distros, I am not aware of any substantial comparison between the different packages.
Looking at the linux kernel would be similar, you need to look at the package definitions to see how they modify the upstream source and also get the upstream source itself. It looks like the QubesOS modifications to the linux kernel can be found in this GitHub repo, although I have not yet spent any time looking at the files in this one.
dom0 Definition
Dom0 is the initial domain started by the Xen hypervisor on boot. Dom0 is an abbrevation of âDomain 0â (sometimes written as âdomain zeroâ or the âhost domainâ). Dom0 is a privileged domain that starts first and manages the DomU unprivileged domains.
The Xen hypervisor is not usable without Dom0. This is essentially the âhostâ operating system (or a âservice consoleâ, if you prefer). As a result, Dom0 runs the Xen management toolstack, and has special privileges, like being able to access the hardware directly.
Dom0 has drivers for hardware, and it provides Xen virtual disks and network access for guests each referred to as a domU (unprivileged domains). For hardware that is made available to other domains, like network interfaces and disks, it will run the BackendDriver, which multiplexes and forwards to the hardware requests from the FrontendDriver in each DomU.
Unless DriverDomainâs are being used or the hardware is passed through to the domU, the dom0 is responsible for running all of the device drivers for the hardware.
Fedora offers a Xen dom0 kernel, as listed here:
https://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen
So its the dom0 Xen kernel which could be an attack surface because Fedora is chosen instead of a distro like Alpine
dom0 is a highly privileged part of Xen and has drivers for hardware, it also provides Xen virtual disks so
it COULD be responsible for a systemd related RDRAND crash.
In my view, due to the very high level of privilege of dom0, this VM creates a rather large attack surface
to the hardware and the hypervisor.
So its the dom0 Xen kernel which could be an attack surface because Fedora is chosen instead of a distro like Alpine
The question is what benefit would an Alpine based dom0 bring, if one still has to include in it all the current extra stuff (XFCE, etc), thus ending up with another non-minimal system.
Unless we have each hardware run its own stuff in an isolated qube, and have dom0 just orchestrate that (instead of include it), we are pretty much stuck.
Well, alpine would be a safer choice, I mean RHEL/Fedora are linked with (insert three letter agency here).
The other thing is, it isnât simple to update the fedora version running in dom0, it still uses f32 according to
the /etc/yum.repos.d/ URLs within this directory
Lastly,
There should be an isolated VM for the disk (sys-disk) and also audio drivers (sys-audio) so that
you can get some isolation for the disk and audio drivers.
This is advantage, actually. EOL, no new/unknown threats, updated from the devs, offline, etc⌠Thoroughly elaborated many times.
1 Like
It is inadvisable to run software that has reached end-of-life status. Developers do not fix existing defects, bugs or vulnerabilities in this case, leading to serious security risks.
This isnât an advantage, how is that an advantage?
For example, in 2018 VLC had reached end-of-life status in May of that year. In that case, Whonix users who did not utilize a different media player were at risk, because VLC in Debian jessie has unpatched security vulnerabilities.
Please backup your statements or at least proove that you read docs:
Hint: Buggy Code vs. Backdoored Code
1 Like