I am happy to announce that the latest release of Qubes Mirage Firewall has just been released (0.9.6). Among documentation and the salt script update, that release adds support for Generic Segmentation Offload (which permits to pass packets up to 64kB between guests, and improves the bandwidth). Currently my network is still the bottleneck as the unikernel does not burn 100%CPU. Unfortunately there is still a missing part to correctly handle windows guests, but it seems to work fine with linux and openBSD AppVMs.
As always, you can update either manually (local compilation with podman/docker, or download from github, check hashsum, copy to dom0) or with the salt formula available on the github repository, or with @unman’s or @ben-grande’s tool.
If you have any comments, please let us know, on this forum or on github.
Nftables are more stable and faster in general. But Mirage is made for maximum security, minimal size, and high efficiency by compiling applications directly into tiny, single-purpose operating systems. Since it is not Linux nftables cannot work. Making nftables to work would have to port the massive, complex Linux network subsystem over to OCaml, which defeats the purpose of Mirage.
Thank you for the new release. I just noticed that sha256 checksum of the release binary (a2be6be545412daf4af794e1ca6ac4f4a93d4eaf9e41f9429ed438e59762d350) does not match the checksum inside the sha256 file (2bfb49696e59a8ffbb660399e52bd82ffadbd02437d282eb8daab568b3261999).
Woups I took the wrong .sha256 local file, a2be6be545412daf4af794e1ca6ac4f4a93d4eaf9e41f9429ed438e59762d350 is the correct hashsum (as the qubes-firewall-release.sha256 file in the repository). I fixed the release on github, thank you for the report!
EDIT: For the record, 2bfb49696e59a8ffbb660399e52bd82ffadbd02437d282eb8daab568b3261999 was the hashsum of the previous release (0.9.5)
You asked about, disadvantages (Mirage compared to nftables), that’s why i mentioned the speed and stability. Those are the disadvantages, even speed is with the latest version comparable with Linux sys-firewall. And extra info is good for everyone who wonder why people suffer stability and maybe speed for something else like Mirage, so i made the purpose of Mirage clear for those who still don’t know. Cause i believe Mirage is a huge plus for security and RAM efficiency in Qubes OS.
About checking performance difference, aside from user experiences, i am not sure if we can easily compare. And i have to add, that when using VPN, Tor, there will be not much difference in speed. Some users had that, but increasing RAM to 64 solved it.
For the comparison (my testbed is very fragile and I find the variance very high, so take them with caution), the latest I have is here Road to GSO part2 by palainp · Pull Request #119 · mirage/mirage-net-xen · GitHub. The ‘-R’ option of iperf3 stands of the download direction (from sys-net to AppVM) in my tests. The upload speed is reduced as ‘no GSO support’ because the clients are responsible for memory management to send packets to netvm, which is a pain if netvm doesn’t support GSO for the time being (I’ve left for another release so far).
The results are not brilliant but I currently the bottleneck is not the unikernel (e.g. with test to ouside world, like fast.com, I don’t have any difference/marginal difference with linux, and for daily networking I don’t have any difference at all).
Thanks for the link. That’s more informative. I wish you had the something like load average values for each test as well but I guess that’s is probably not as trivial for the unikernel.
The unikernel is near idle all the time and goes up to 50℅ when I download a file.