What are the Dom0 security risks of the Mirage-firewall installation process?

As someone who is unable to review code, I wonder about the process of installing mirage-firewall.

In the process you have to copy the vmlinuz unikernel in to dom0.

Copy vmlinuz to /var/lib/qubes/vm-kernels/mirage-firewall directory in dom0, e.g. (if dev is the AppVM where you built it):

How secure is this process if a user is unable to build and read the code themselves? From a non-technical perspective this kind of copying in to Dom0 would seem to represent a serious security concern.

So as there is no signing on the unikernel or verified hashing how should an individual who cannot personally audit the code weigh the potential security benefits of a reduced attack surface of mirage & additional OS in their security chain with the risk of execution of unverified/signed code in Dom0?

Are there plans to move toward a signed mirage template in the Qubes repo?

I’m aware in general that if you can’t read the code you are always exposed to risk, but perhaps the risk to such a crucial security pillar as Dom0 is not worth it for a user like me until I can lean on the signed verification of the unikernel from QubesOS team (an entity I chose to trust).

Thanks for your input.


Is anyone able to answer this?

Hi, this probably won’t the best answer for you :frowning:

The builds of qubes-mirage-firewall are reproducible and you can check the hashum of the resulting vmlinuz against qubes-mirage-firewall/build-with-docker.sh at 609f5295c7b315886244426b685807244c7dbe81 · mirage/qubes-mirage-firewall · GitHub (it should always match the released version on github) and the commit updating the hashsum should also be signed by a qubes-mirage-firewall dev. Also there are daily builds (with hashsum) on the ROBUR site (https://builds.robur.coop/job/qubes-firewall#builds).

The review process for integrating qubes-mirage-firewall into community packages is ongoing ([Contribution] Qubes-mirage-firewall kernel or template · Issue #7884 · QubesOS/qubes-issues · GitHub) and until that is done, your only option is to trust the qubes-mirage-firewall developers in addition to the Qubes devs (this is the part that might not fit your trust path).


If you want then just install it.

Answer here is simple. If you really have danger then you don’t play with qubes. So far mirage-firewall is nothing essential. It reduce memory from 800mb to 32mb. For person who worry about their safety it’s not a question.

The main idea of qubes that “It’s not possible to check all code.”

Also there are idea of risk management. How really one have risk?

I run qvm-run -p vm "cat file" > file pretty often :v:


That is a great response. I’m not as concerned about mirage itself per se, more the threat of a malicious replacement / alteration in transit that I’m then delivering straight to Dom0 as a trojan horse.

The fact that it’s reproduce-able and I can checksum it is exactly what I was looking for. Thank you.

@anon-98765 Yes, I understand. Thanks. Your command is a useful reminder for me that I can do this, rather than directly move the file itself across.

If I cat the file in to a file in Dom0, does that work for something like vmlinuz? Is it simply a file in this way? Pardon the ignorance and ignore the question if it is too confused, I’ve gained a lot already from these responses.