Sebastien Roy wrote:
> All of these cases could be addressed easily if we either always had a
> conn_t, or the DB_CRED(mp) were accurate at the hook locations (except
> for kernel-generated packets...). Ignoring the fact that IP data-path
> refactoring will blow this all up, I know that the former isn't true
> today, but I wonder if the latter is. Do you know? Could (until
> data-path refactoring delivers) we simply use DB_CRED() in all cases
> instead of the source IP address?
We do not set db_credp for all transmitted packets. And since it is a
scaling problem (crhold/crrele end up clobbering the same refcnt per
userid) there is work in Volo to further reduce use of db_credp. We
currently do set it all the time when TX is in use, but that doesn't
help here.
Thus I think the best thing you can do for now is the source address lookup.
>> In the onnv-gate code base it is hard to do something about those cases.
>> But my question is whether we actually want to capture the zoneid of the
>> sending process. (It would be easy to do that in the refactored IP code.)
>
> We need to, yes, because filtering is based on zoneid. For example, a
> stream originating in zone A should only be able to see packets
> originating from zone A or destined to zone A, and this filtering is
> done in the ipnet module based on the zoneid's associated with the
> source and destination.
ok
>> But if we do that things will not be symmetric with the receive side
>> (the destination zoneid on the receive side to be specific.)
>> For instance, while we can know the sending zoneid when SO_ALLZONES is
>> used, on the receive side it isn't until we hit the top of IP (looking
>> for a conn_t) that we can tell that SO_ALLZONES was used. Likewise for
>> the TX shared IP address; we do a fanout once we know the label. (Hmm we
>> do know the db_credp early on in ip_input with TX; I don't know if the
>> cred has the zoneid set at that point in time though.)
>
> tsol_get_pkt_label() fixes the label in the db_credp early on (early
> enough), then the ipobs code does a tsol_packet_to_zoneid(mp) which
> turns this label to an accurate zoneid.
Be careful in how db_credp is overloaded.
The db_credp set in tsol_get_pkt_label() is based on the *sender's*
label, and it isn't a complete db_credp (I think cr_zone might be NULL;
I remember being bitten by something in that space.)
In any case, that isn't always the same as the *receiving* zone; with
MLP the application might run in a zone which has a different label the
the sender.
Thus it is the case that we do not know for sure the zone in which the
receiving application runs until we have located the conn_t.
You could argue that the cases when we could get it wrong (by looking at
db_credp when TX is used are insignificant or unimportant; e.g., if TX
prevents ngzs from using snoop in any case (I don't know if TX does
that; just speculating.))
But my point is that some significant care is required in such an argument.
>> For IP_UNSPEC_SRC the corresponding receive side is a multicast or
>> broadcast packet. I went back and re-read your design document and I
>> didn't see any examples in how multicast and broadcast is handled.
>>
>> How does the multicast and broadcast packets match non-global zones in
>> ipnet?
>
> This is indeed missing from the design doc, and the code currently
> doesn't handle this correctly (we have a bug filed on this). The
> desired behavior is that the destination zoneid of multicast and
> broadcast packets are unknown. All zones are allowed to observe
> multicast and 255.255.255.255, and subnet broadcast is filtered based on
> the IP interface being observed.
OK
> The PSARC materials (2006/475) contain some discussion on how
> DL_PROMISC_MULTI causes the ip module to enable DL_PROMISC_MULTI on the
> underlying device so that we can have observability of all multicast
> traffic, and not just the traffic associated with joined groups.
But for both multicast and broadcast I assume you restrict it to ills on
which the zone has an ipif. Is that correct?
>> In my head it also isn't clear how to handle certain transmitted packets
>> generated by the kernel. The tricky one is IPv6 ND packets where we've
>> had various attempts at determining the zoneid. The ND packets, just
>> like ARP packets, are essentially sent as a part of a service which is
>> shared for all the zones (the ARP and NCE information is shared for all
>> the zones.) However, the ND (and ARP) packets have a source IP address
>> which is assigned to some zone. I don't know if the current onnv-gate
>> code uses that as the zoneid passed to ip_output.
>
> Good question. The definition of "correctness" isn't all too clear to
> me either. Using the zoneid associated with the source address would
> allow zones to view ND packets sent on their behalf. On the other hand,
> since the "process" of neighbor-discovery is essentially in the global
> zone and the packets are generated from the global zone (but this is not
> well-defined, but then again zones in general are poorly defined),
> associating those packets with the global zone would not seem
> incorrect. :-(
Zones are well-defined; it is merely shared-IP zones that have
definitional problems.
Erik
