Hi, I was considering to use Kicksecure but I’ve encountered Mirage OS (https://mirage.io/), what do you recommend? Thanks!
1 Like
Qubes-Whonix.
2 Likes
Vms → mirage-firewall → sys-net or Vms → sys-vpn → mirage-firewall → sys-net for clearnet
Vms → sys-whonix → mirage-firewall → sys-net for tor.
Personally, i just use kicsecure for sys-net and sys-vpn.
1 Like
sys-mirage for me is a no-go.
It only allows for a single cpu core and manages on modern hardware just around 250mbits.
Maybe specialized if a vm needs special handling and one would need to save ram …
1 Like
These are not really deal-breakers, since it’s a supper light unikernel there is no need for a second core, and 250Mbits/s is plenty. Although, I didn’t find that speed limitation in their documentation. If you can provide a link, I’m curious about the reasoning there.
sys-firewall is one of the the most vulnerable qube. If there is something better out there, it’s worth looking into.
I’d like to know the pros and cons of Mirage OS, versus what I’m currently using, which is Kicksecure-18.
2 Likes
I barely break 50 Mbit/s with using Mirage due to Mullvad VPN anyway with me having turned on ALL of the options (if I’m paying for all of the options, I’m gonna USE all of the options (ex: DAITA, Quantum Resistance, Multihop, Shadowsocks, and DNS blockers)).
Currently residing in a VPN blocking/restricted country and Mullvad VPN works the best compared to ExpressVPN – seems like the local government keep clamping down on their servers since it’s the most popular/known one, maybe?
Also, I setup my disposable sys-net to use a fresh Fedora 43 minimal one with selinux setup on it and the bare minimal packages. Looking into OpenBSD for sys-net sounds kinda nifty… but that sounds like a 3+ day weekend thing (Presidents Day project, maybe?).
1 Like
What did you use before Mirage OS. How does it compare?
1 Like
I was raw-doggin’ it with ExpressVPN with the default sys-firewall and non-disposable sys-net.
AppVM → sys-firewall → sys-vpn (ExpressVPN) → sys-net (non-disposable)
The speeds were great, but occasionally I would be offline from half a day to a whole day sometimes because I would be unable to connect to the ExpressVPN servers.
My current setup looks like this:
AppVM (~80% are disposables) → sys-firewall (disposable) → sys-vpn (Mullvad VPN & disposable) → sys-firewall-outer (Mirage) → sys-net (disposable, minimal Fedora 43 w/ SELinux)
1 Like
Just tested it with speedtest.net against a default debian minimal 
Gemini takes the same stance and refers to issue #130
In detail:
1. Lack of TCP Segmentation Offload (TSO)
The primary technical bottleneck is that the Mirage network stack (specifically mirage-xen) currently lacks support for TCP Segmentation Offload.
The Impact: Without TSO, the CPU must process every single packet individually rather than offloading large chunks of data to the network card. This significantly increases CPU overhead during high-speed transfers.
Source: In a Jan 2025 discussion on the Qubes Forum, developer palainp stated: "We have, for the time being, a lower maximum bandwidth with TCP vs linux kernel, and I currently put the fault on the lack of TCP segmentation offload in mirage-xen."
2. Single-vCPU Architecture
MirageOS unikernels are traditionally single-threaded.
The Impact: Unlike a Linux-based sys-firewall which can scale across multiple vCPUs to handle heavy traffic, Mirage is restricted to the performance of a single core.
Source: Community testers noted that while Mirage uses 32MB of RAM, its single vCPU often hits 100% utilization during high-bandwidth tasks (like torrenting or iperf3 tests), causing it to bottleneck at speeds well below gigabit.
3. Real-World Benchmarks (iperf3)
Specific benchmarks comparing sys-firewall and mirage-firewall consistently show this gap:
Source (GitHub Issue #130): User grote provided detailed iperf3 logs showing:
sys-firewall: ~716 Mbits/sec
mirage-firewall: ~174 Mbits/sec (baseline)
mirage-firewall (optimized): ~446 Mbits/sec (after applying flambda compiler optimizations and best-fit allocation).
Source (Qubes Forum): In late 2022, benchmarks showed Mirage achieving about 73% of Linux's bandwidth for TCP (510 Mbps vs 700 Mbps in that specific test environment).
2 Likes
Mirage is a great project. Unikernel design is very promising for service qubes. It consumes little memory compared to conventional systems and should have extremely small attack surface. Kind of what liteqube dreams to be 
. On the other hand, mirage in general and stuff like mirage firewall for qubes are young projects with some unfixed flaws.
Kicksecure is a security-oriented full-fledged linux distribution based on debian. Pretty much just a hardened debian.
There aren’t that much to compare, they are very different and there should be little functionality overlap.
Just FYI, from https://en.wikipedia.org/wiki/Unikernel:
A unikernel is a type of computer program that is statically linked with the operating system code on which it depends. Unikernels are built with a specialized compiler that identifies the operating system services that a program uses and links it with one or more library operating systems that provide them.
If you want a unikernel, use mirage, and if you want a desktop OS, use kicksecure (although whonix might be a better choice, but it’s a different topic)
1 Like
Single purpose qube. You don’t get much smaller attach surface than that.
Doesn’t sound too hard to implement either, certainly worth the try imo.
I’ll check it out for sure!
1 Like
Would you explain what makes you think this is?
Because in practice this is the most safe place in a Qubes architecture - if you ask me 
The most vulnerable will be always your AppVMs. As this is the place where you - as a user - actually doing things… and making mistakes.
This is the place where your private/work/whatever data actually lives.
This is the place which is actually communicating with the possible malicious sites on the internet.
The second most vulnerable is your sys-net, as it is directly connected with the external networks. Still not as vulnerable as the appvms, as by default nothing is allowed to access from ‘outside’. The ‘only’ vulnerability might be in the firmware of your network device, which - if exists - still requires much more skills and efforts to exploit, than your average browser running in your appvm.
And the most safe place is your sys-firewall. Even if the name suggest otherwise, actually it is separated from the external network, technically nothing can ‘hit’ it from that direction
From the AppVM side, it is still just a packet filter and forwarder, so unless there is a huge security hole in the IP stack of the OS you run there, even a malicious AppVM can’t really do nothing to break and/or compromise it.
That’s the whole point having it as a separate VM: as even your AppVM is compromised, it can’t compromise the firewallVM, so you firewall rules are still in place, and not letting the AppVM go wild.
1 Like
I’m assuming no user error. Qubes OS has very good security to protect from online attacks. It’s hard to image getting to sys-firewall from an appvm.
For the purposes of this conversation, I agree that the most vulnerable qube is sys-net.
An attacker can get, for example, all your wifi passwords (from every wifi you ever connected), and doesn’t even need sudo privileges to do that. WIth no package filtering at sys-net, it is not very hard to imagine an attack to sys-firewall, from a sophisticated attacker.
If that person gets to sys-firewall, he/she can monitor everything!
1 Like
No, it is still not the case…
You really think that wifi passwords are actually private?
Well, at least Google, Apple and Microsoft is knowing (and carefully creates backups ‘for you’) all of your wifi password, with GPS coordinates next to it 
And this not even the point, but how would an attacker get into your sys-net?
Again: how do you imagine such attack scenario?
If you have your answers, then compare it with: how easy is to get into your AppVMs.
And from that, you might see the whole point of using Qubes OS:
As it is not even suggest that you can really protect your AppVMs, but it promise you that such attack will not immediately affect your whole workstation, thanks to the separation of you digital assets to virtual machines.
And no, even if an attacker ‘gets to’ your sys-firewall - which is the least realistic assumption - he can’t monitor ‘everything’… As ~all of your communications are TLS encrypted nowadays. and initiated from the AppVM(s)
1 Like
Cool ! An interesting discussion about Mirage that I can participate in ! You should not take my words as those of the Mirage community. I am speaking only for myself, as a developer within the Mirage community
Regarding the speed issue, Mirage has lower bandwidth than Linux when using iperf tests locally or on remote site, and using remote testsites. To the best of my knowledge, this is mainly due to the lack of segmentation offload, which Linux is capable of, unlike Mirage.
This is very noticeable in bandwidth tests, as streams generate many MTU-sized packets (say 1500 bytes), and segmentation offload allows them to be grouped into larger packets (at least 2 per 4 kB page, and up to 64 kB). This reduces the number of memory dances required between two virtual machines, and the sys-net virtual machine recreates normal IP packets.
It should be possible to try the same speed test without segmentation offloading (i.e., using “sudo ethtool -K eth0 tso off”) in sys-firewall, and the difference between mirage and linux should be less noticeable.
That said, I’m not satisfied with the current situation and would prefer to be able to enable segmentation with mirage as well, but that’s something really big to implement And in the sametime, I don’t see much difference in everyday network use (i.e., sending emails or browsing, when the flows are not continuous packets from an AppVM to a remote server) between Linux and mirage, so I’m currently satisfied with that, and others seem to be as well.
As for the singlecore issue, even though mutlicore would help increase bandwidth, I think it’s more of an “ecology-friendly” feature, just like memory footprint, for a service VM. Since Ocaml 5 is multicore, we may be able to use multicore processing one day, but this is also something that would be significant to implement
Finally, what I appreciate about Mirage are:
- its stateless approach (no configuration is written/saved by the kernel from one session to the next),
- the Ocaml language, and the compiler, which is a bit strict about the use of variables and memory,
- the code base is completely different from other kernels, so zero-day attacks targetting the linux kernel would probably have no chance against Mirage kernels (if someone manages to “break into” an AppVM, whether from a client AppVM or sys-net, there is no way to get a remote shell to the firewall VM, and little or no way to attack further down the network chain).
6 Likes
OK, care to share why?
So you are saying if big tech has the passwords, there is no point of hiding them?
I’m also worried about the attacker knowing all the network SSIDs I’ve connected to and start building a picture.
This is not a Si-Fi senario, it’s a linux vm connected through the network!
An attacker can exploit misconfiguration and weak rules (or even change them with enough access), they can choose to attack other vm’s on the same network, malware and payload delivery, etc. These attacks have happened.
If someone tries to attack a Qubes OS, chances are they do know what they are doing.
I’m surprised you feel so confident about your setup that you are not willing to consider documented attacks on such setups (not exclusively on Qubes OS).
I don’t think this is a discussion to have in this thread. I suggest opening a new one.
1 Like
I set up a MirageOS sys-firewall vm and it works as advertised. Saved a few hundred MB of RAM in the process, but the big win is the small attach surface.
Updating it manually every time a new release comes out is not ideal.
@otter2 Any idea when we’ll see an official Qubes OS template?
1 Like
The correct answer is that I don’t know, I’m not a part of Qubes OS team or mirage team.
The real answer is never, probably. Why? It’s a unikernel. It can be distributed via rpm as any other kernel, no need to make a template out of it.
1 Like
Using OpenBSD is also a relatively secure option: Fortifying sys-net: A Shift to OpenBSD
1 Like
So are you saying there’s no difference if I’m using linux with above 1GBit connection and mirage? Or is it just personal thing?
Others who use it you mean? Don’t you wanna target these who don’t, but would like to?
2 Likes