Mirage-firewall and Qubes OS

I know that every time low memory installations of Qubes OS are discussed here, someone suggests replacing sys-firewall with mirage-firewall. I wanted to give it a try and headed over to the GitHub repo to find out that the code hasn’t been touched in 3+ years, the compiled tarball doesn’t exist anymore and the code may even be in a state where it doesn’t cleanly compile anymore with the current versions of Fedora/Debian/Docker (but haven’t tried it myself). I didn’t see any bug reports, which is quite concerning and could indicate that either it’s been written by the best programmer in the world or that mostly nobody uses it. I love functional programming languages (mostly non-strict lazy Haskell but I’m comfortable with strict ocaml too) and I appreciate the expressiveness, but no bugs at all in a thousand lines of code? come on! :slight_smile:

Questions: How much trust/faith on mirage-firewall do people have around here? Should people stop recommending it until an active maintainer starts feeding and caring for it?

1 Like

 

I wanted to give it a try and headed over to the GitHub repo to find out that the code hasn’t been touched in 3+ years

According to its Github, the code was last updated 5 months ago.

 

the compiled tarball doesn’t exist anymore

The tarball seems to be alive and well (see the “Releases” section), but the last release is dated June 2020.

 

While I share your sentiment regarding the seeming lack of updates (see this post) and would love to hear something from the maintainer, your post is full of flat-out misinformation of the worst sort–stuff that one could verify by just looking at the Github. Or maybe we’re somehow talking about different things.

I also want to bring up the possibility that a microkernel, by its miniscule nature (tarball is 2.04 MB), doesn’t need frequent updating and the recent updates are enough. If you want these updates, you’ll have to compile them yourself instead of relying on the tarball though.

 


Not technically-trained; consume with salt

1 Like

Well, I hope you didn’t feel like I was trying to misinform anyone. I may have just been misinformed myself, though :slight_smile:

Now, I went back to the github repo and saw that there were updates from 5 months ago, so things are not as bad as I thought. I’ll give it a try and compile it from the current master.

I still would like to hear from people who trust it and use it. Is it a few? A dozen? Hundreds?

1 Like

They are currently working on new release and Qubes Community template. If You want build it yourself it will either not build or not pass checksum validation since there was some changes in toolchain.

2 Likes

Oh, that’s great to know, @Szewcu. Thanks!!! You saved me some time fiddling with it today!

In the meantime, I’ll just use a debian-11-minimal as sys-firewall instead to save a couple hundred megs, and will try Mirage when it becomes a Qubes Community template.

1 Like

That’s really great to hear! Where did you get this information?

1 Like
1 Like

That’s good to hear. Looking forward to that being released. If the RAM-gains are really 1/10th compared with using the fully-fledged Linux kernel, and if the bandwidth speeds are not at least the half compared to Linux kernel, then, I think many people might opt-in to using MirageOS for firewall-vm.

I started using mirage firewall 0.7.1 a couple of weeks ago and moved to the 0.8 build a couple of days ago. Been quite happy with it so far. The only drawback of the latest 0.7.1 build is that it will only run as a PV, but if you get one of the nightly builds of 0.8 here (Job qubes-firewall on freebsd-12) you can use that version in PVH and not need to compile it yourself. 64MB of RAM and no swap at all are a good perk to have. Performance is not very relevant to me since my wireless usually caps around 300Mbps.

1 Like

That’s just amazing.

On another thread, I was reading about an idea that going forward, sys-firewall, sys-usb, etc. should all have dedicated minimal unikernel setups, similar to MirageOS for sys-firewall.

I fancy that idea from the perspective of freeing up RAM used on QubesOS machines. Since one can compartmentalize his own computing activities across tens of qubes, that person would need lots of RAM. I would like to be able to run tens of AppVMs in a 16 GB RAM machine.

Seek for minimal templates. Don’t seek for mirage ones.

That’s because you need all those drivers in sys-usb and sys-net, just as Marmarek has mentioned.

Probably mirage general-purposed qube isn’t a good idea, either. You need multimedia be played in firefox, and that’s a lot of things to do, etc.

If you are really strict on RAM, and don’t care about SSD performance and/or life, then you can assign very few RAM to your qubes. They will actively use their (not dom0’s) 1GB-sized swap (on xvdc). Sometimes you notice your disposable qube’s disk usage is 1GiB or more, that’s probably because it is using swap.

1 Like

I understand this. And this advice is specifically for sys-usb and sys-net, as these two are closely interacting with the hardware (sys-usb with the usb ports, and the sys-net with the wifi/ethernet card).

Thus these two sys qubes should have appropriate (and specialized) drivers installed into.

But, as far as I am able understand, sys-firewall is just a internet packet forwarder. It doesn’t interact with a specialized hardware that it needs to have specialized firmwares for. Sys-firewall just forwards (or drops/blocks) packets from sys-net into the appropriate qubes. And, thus, MirageOS implementing just the simple logic for packet-forwarding can afford to be stripped off of the specialized firmware software.

When I mentioned reading on another topic in which sys-usb and sys-net, too, were also MirageOS-like light unikernel and specialized ones, I was not thinking about implementing MirageOS to them. I was hopeful that in the near future there would be other MirageOS-like solutions would be developed, which would only house the necessary firmwares for the -usb and -net qubes.

This could be interesting for you:

1 Like

It is! Thank you very much!