On Sat, Jan 2, 2016 at 12:07 PM, Thomas Leonard <[email protected]> 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 `online=1`). The frontend can then plug itself back in. In the case of a toolstack-initiated hot unplug, the toolstack will set `online=0` 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 > [email protected] > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > -- Dave Scott
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
