[MirageOS-devel] A Unikernel Firewall for QubesOS

[Thomas Leonard <talex5@xxxxxxxxx>]

I have a Mirage firewall running now under Qubes:

  http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/

There are some things that need fixing though:

- I'm using an old version of mirage-nat, as the current version
requires Irmin. I think there were some plans to factor this out -
what's the status of this? I think only the new version has code to
expire entries, right?

- You need to generate an unused port for NAT. I copied simple-nat's
system of picking a random number and retrying but (as the TODO there
says) this will eventually run out of ports and hang. I assume we
should add some kind of free-port tracking to tcpip, right? pcb.ml's
getid has a better strategy of searching forward from the last port it
used, but it will also hang if it runs out (as noted by another TODO).
The UDP code doesn't seem to track free ports at all (fails with a
TODO if you ask it to pick a free one).

- I'm not sure what the protocol is for disconnecting netback clients.
Currently I just set the interface state to Closed, but the XenStore
directory in "backend/vif" remains - is this documented somewhere?

- Mirage allows you to access memory after unmapping it. This isn't
safe (may page-fault or give access to someone else's data). I've
added checks in mirage-net-xen to make sure we don't try to access a
ring after unmapping it [1], but I think this should be fixed at the
Bigarray level [2].

- mirage-nat doesn't do NAT for ICMP packets, so ping doesn't work yet.

- mirage-nat mutates packets in-place. It might be cleaner if it made
a copy instead (it could copy just the header and return [new_header;
old_payload]). Since mirage-net copies the data into the shared ring
anyway, there should be very little overhead to doing it this way.

- mirage-nat works on whole Ethernet frames. I believe NAT only
applies to the IP layer - it would make my code cleaner if I could
strip off the Ethernet header when the frame arrives and just work
with the IP layer. It might simplify the mirage-nat API too.

- I don't validate checksums on incoming packets, and always
recalculate after NAT before sending. We should probably track this
properly and support checksum offload. This will require an interface
change to NETWORK.

- I made some changes to mirage-nat (exposed checksum code in tcpip
and used that directly, and removed the unused "direction" argument as
it was confusing me). Might be useful to merge these upstream.


[1] 
https://github.com/mirage/mirage-net-xen/compare/master...talex5:disconnect?expand=1
[2] 
https://github.com/ocaml/ocaml/commit/af6f20ef0afc4f8ab9d3cc89042038b55930e09d

-- 
Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel