[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Sat, Jan 2, 2016 at 12:07 PM, Thomas Leonard <talex5@xxxxxxxxx> wrote:
I have a Mirage firewall running now under Qubes:


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:

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.



- 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

Dave Scott
MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.