If dom0 were to move away from Fedora as the OS for dom0; what would be the criteria for choosing an alternative?
https://www.hardenedbsd.com/content/easy-feature-comparison
opened 04:34PM - 18 Apr 16 UTC
T: enhancement
C: core
P: major
We have discussed this numerous times but don't have an issue to track these dis⦠cussions. It would be worth understanding what would be needed to change dom0 from Fedora to Debian (say Debian 8). Benefits include:
- increased hardware compatibility
- incorporate serious work taken towards reproducible builds
- better firstboot installer
- better (slower) release cycle than Fedora with longer-term support
- other things?
This ticket does not encompass modifying the desktop environment.
https://www.gnu.org/distros/free-distros.html
1 Like
bored
January 31, 2023, 1:36pm
2
1 Like
SeL4 is a microkernel. Any thoughts on using a Rust-based hypervisor like Gramine? or Occulum?
(or are these projects just to take advantage of Intel SGX enclaves).
What about a unikernel (LibraryOS) like mirageOS for dom0?
2 Likes
Sven
February 2, 2023, 5:19am
4
Please familiarize yourself with Qubes OS architecture and then see these threads:
Iām trying to summarize and redirect Github discussions about alternative dom0 distros to the forum. These discussions surfaced the following developer concerns:
Long Term Support (reduce update churn).
dom0 gets updated between 1-3.5 years/~1.9 years on average.
Up-to-date userland (updated packaging, large support community).
This will be less important as more functionality is moved out of dom0.
Up-to-date kernel (good driver/hardware support).
Small TCB.
āSecureā packaging (reproduā¦
I wanted to continue discussion from the Debian in dom0 and Alt RPM Distro (CentOS, RHEL, Suse, Oracle Linux) in dom0 tickets. To keep discussion on track, this thread is to discuss RPM based distros only.
Recap
The short Fedora release cycle is a drag on development, but sticking to a Red Hat adjacent distro has many benefits:
A lot less work than switching to Debian or Nix.
Efficiency gains from using the same distro in dom0 and VMs (via UBI or Fedora CoreOS/IoT ).
A lot of money is poured ā¦
We all know Fedora is a big name, but is it a good choice for a Security Driven OS like QubeOS to be based around?
I found it interesting reading that it was mentioned about the Surface Attack on some things related to QubeOS because it was small in size, like the code, not containing much, therefore limiting the Surface Attack.
Ok, GREAT point, but what about the IDEA that if you use a BIG DISTRO like Fedora and the MASSIVE SIZE of the repos and the software contained in it, this sounds like ā¦
and also
Hi I just found Joanna Rutkowskaās blog post Qubes Air: Generalizing the Qubes Architecture where she states that that is the next step for Qubes-OS. The article was written in 2018. So, I wonder whether thatās still the objective; getting Qubes in the cloud? Really?
These discussions should give you a comprehensive idea of all the ideas that have been discussed, the reasoning behind them and links to plenty of material relevant to this question.
3 Likes
Sven:
then see these threads:
Heh. I was about to link to them before I saw your response
2 Likes
Sven
February 2, 2023, 5:36pm
6
Yeah, this is a very good candidate for an FAQ entry. Something along the lines ofā¦
it doesnāt really matter, because offline / no user interaction / hardware isolation
itāll be even less important in the future or go away anyway, because more hardware isolation (net, usb, audio, gui domains)
if an attacker reaches dom0 your hardening / favorite distro wonāt save you
3 Likes
Is this the canonical thread for the āother distribution for dom0ā conversation? Iām thinking no?
I noticed the Github issue was set to āthis is not the best place to discuss thisā, but itās not immediately clear to me where to go to follow or participate in that discussion
The issue links to this Discourse group URL , but that fails to load for me
Though I donāt have much currently, I would be happy to contribute whatever time I do have to development or testing. Iām capable of (at least) building, developing glue and testing
⦠from the Github issue though, it seems to me thereās still considerable work and discussion required just to determine what distribution would be suitable, and why
My interest is backed by a pretty weak case - would be very happy to be rid of Fedora (or any RHEL-based distributions) simply because I donāt like using them, as a function of not knowing their tools and conventions well in the way that I know those used by Debian. Not reason enough to make a serious argument for all Qubes developers and users, I admit
Is the best place for this discussion in the real-time chat app used by Qubes devs? (Forgetting the name but I have a Qube set up for it that I just havenāt yet actually used)
Iāve considered itās very possible this isnāt really āa thingā anymore, due to priorities and a possible lack of substantial āpainā from Fedora
1 Like
adw
December 8, 2024, 3:32pm
8
Thatās because the issue tracker is not intended to be a discussion forum .
This is the discussion forum, so the best place is either here or one of the mailing lists .
You have to replace qubes-os.discourse.group
with forum.qubes-os.org
, because the forum changed domains a long time ago.
Itās supposed to redirect automatically , but it looks like thatās no longer working for some reason.
3 Likes
deeplow
Split this topic
December 10, 2024, 2:14pm
9
skyvine
December 15, 2024, 2:42pm
10
Thereās a GitHub PR stating that ābasic functionalityā works for NixOS as Dom0. I havenāt tried it myself though.
NixOS:master
ā CertainLach:qubes-packages
opened 03:55PM - 11 Sep 24 UTC
## Description of changes
You can initialize qubes database files using `qube⦠s-create` from `qubes-core-admin`, and then you need to install some virtual machines - this can be done by running qvm-backup on QubesOS system, and qvm-backup-restore in NixOS.
After that, basic functionality will work.
Be careful with netvms, as dom0 updates will not work with them. Some loosening up of qubes security needs to be implemented, at least having "qvm-dom0-network-via-netvm" script (Which was present in QubesOS before, and now needs to be written from scratch?) would be a good start.
At this point, you're welcome for testing, but be aware that it is not finished yet.

Cc: @SigmaSquadron
## Things done
- Built on platform(s)
- [ ] x86_64-linux
- [ ] aarch64-linux
- [ ] x86_64-darwin
- [ ] aarch64-darwin
- For non-Linux: Is sandboxing enabled in `nix.conf`? (See [Nix manual](https://nixos.org/manual/nix/stable/command-ref/conf-file.html))
- [ ] `sandbox = relaxed`
- [ ] `sandbox = true`
- [ ] Tested, as applicable:
- [NixOS test(s)](https://nixos.org/manual/nixos/unstable/index.html#sec-nixos-tests) (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
- and/or [package tests](https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#package-tests)
- or, for functions and "core" functionality, tests in [lib/tests](https://github.com/NixOS/nixpkgs/blob/master/lib/tests) or [pkgs/test](https://github.com/NixOS/nixpkgs/blob/master/pkgs/test)
- made sure NixOS tests are [linked](https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#linking-nixos-module-tests-to-a-package) to the relevant packages
- [ ] Tested compilation of all packages that depend on this change using `nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"`. Note: all changes have to be committed, also see [nixpkgs-review usage](https://github.com/Mic92/nixpkgs-review#usage)
- [ ] Tested basic functionality of all binary files (usually in `./result/bin/`)
- [24.11 Release Notes](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2411.section.md) (or backporting [23.11](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2311.section.md) and [24.05](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2405.section.md) Release notes)
- [ ] (Package updates) Added a release notes entry if the change is major or breaking
- [ ] (Module updates) Added a release notes entry if the change is significant
- [ ] (Module addition) Added a release notes entry if adding a new NixOS module
- [ ] Fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md).
<!--
To help with the large amounts of pull requests, we would appreciate your
reviews of other pull requests, especially simple package updates. Just leave a
comment describing what you have tested in the relevant package/service.
Reviewing helps to reduce the average time-to-merge for everyone.
Thanks a lot if you do!
List of open PRs: https://github.com/NixOS/nixpkgs/pulls
Reviewing guidelines: https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#reviewing-contributions
-->
---
Add a :+1: [reaction] to [pull requests you find important].
[reaction]: https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/
[pull requests you find important]: https://github.com/NixOS/nixpkgs/pulls?q=is%3Aopen+sort%3Areactions-%2B1-desc
1 Like
I often encounter Alpine Docker images when deploying and administrating software on my servers: