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
2 Likes

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!

It just caught my eye that my sys-firewall (based on debian-11-minimal template) is occupying ~4GB of RAM space.
That 65 MB of RAM usage for MirageOS is just too sweet.

1 Like

Yes, it is! You can certainly shrink the standard sys-firewall and it should run in 400MB or so, but Mirage is still a small fraction of that footprint.

2 Likes

I wonder what would it take to get “official” developer support from QubesOS developers for MirageOS for its ready-made use in QubesOS.

I really don’t know. I’ve seen conversations in the forums for years and yet it’s not there today. I don’t know if this is really a priority for them or if they just accept the fact that people may need more memory and memory is cheap nowadays.

1 Like

Yeah, it is a curious case that MirageOS as a sloution for Firewall’ing in QubesOS has been announced and been around for the past 6 years; yet, despite its amazing simplicity and savings in RAM usage economics, QubesOS devs didn’t decide on deploying/supporting it “officially” (meaning, it can be installed via a simple qvm-template install command or during the initial QubesOS install from a drop down menu).

I agree! That would be wonderful. But instead of that, if you are really interested in it you need to figure out how to deploy it yourself (learning quite a bit about qubes in the process, which is a plus, of course). On top of that, since there are bugs and issues, you need to pick the right nightly build that works, doesn’t have a nasty memory leak and doesn’t break your qubes every few days.

2 Likes