Xen project Mailing List

On Sat, Jan 2, 2016 at 12:07 PM, Thomas Leonard <talex5@xxxxxxxxx> wrote:

I have a Mirage firewall running now under Qubes:

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

Excellent stuff!

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?

I used to believe that the toolstack's job was to manage (create + destroy) the backend/frontend directories in xenstore, and it was up to the backend and frontend implementations to keep their important state somewhere safe (i.e. not xenstore or in shared memory, where another party could modify it and invalidate some invariant). For example if someone runs `xenstore-rm <backend>` I imagined the backend would still remember its configuration and would be able to clean up afterwards, and not leak.

However I think the policy changed in September, probably to accommodate not-very-defensively-written backends:

https://github.com/mirage/xen/commit/546678c6a60f64fb186640460dfa69a837c8fba5

It looks like the driver domain now has to delete its own directory, when it has finished using it.

BTW it just occurred to me that the Windows PV drivers perform an interesting hotunplug-hotplug dance when they are first connected (apparently this is caused by a strangeness of the Windows driver model). To make this work we'll need to support the `online` backend key -- basically the frontend can initiate an unplug at any time, which should cause the backend to close but not delete itself (because ` The frontend can then plug itself back in. In the case of a toolstack-initiated hot unplug, the toolstack will set ` first, so the backend will know it's safe to self-delete.

Cheers,

Dave

- 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

Dave Scott

Re: [MirageOS-devel] A Unikernel Firewall for QubesOS