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

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 2 Jan 2016, at 12:07, 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/
> 

Awesome!

> 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).

Yes, we need a standalone free-port picking datastructure for a few things:
- udp source port selection
- tcp/ip source port selection
- ipv4 id selection also needs some form of non-repeating selector
  but we don't currently fragment outbound at the moment.

For randomising this, a linear congruential generator is what the
OpenBSD stack uses.

> 
> - 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?

Good question, not sure.

> - 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].
> 

Did that Bigarray patch get committed into OCaml 4.03dev?  I dont
have a checkout handy here and it's hard to map a commit to the 
associated PRs in the web UI.

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

Presumably this also means that UDP NAT doesnt work?

> - 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.

Yeah, there's a general need for feature flags to be added to the
NETWORK device interfaces...

Looking forward to trying this out on my Cubieboard at home soon!

Anil


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