On Friday 01 January 2016 16:25:59, Theo de Raadt wrote: > dlg writes: > > should we just do it unconditionally? is there a downside to that?
It may decrease performance a tiny bit. Since such bits tend to add up, I would be hesitant to enable the check for drivers that don't need it. OTOH, freebsd and linux seem to always do the check. > > That is a very good question. What are the downsides against having > the driver do this filtering itself, like all real hardware does? The driver would need to do some mbuf operations to get the destination address. The same operations are then done again inside ether_input(). This is ugly. > Why risk sending packets of the wrong form further upwards into the > network stack, and then having to ensure the checks exist up there? > > This flag is requesting special service to encourage a layer > violation. > > What is the reasoning to encourage such a flag (which someone will > one day see, misuse, and try to expand for their bizzare use > case...) To me, it seems as much a layer violation as hardware checksum offloading features or the IFF_SIMPLEX flag. So no change there. On Saturday 02 January 2016 10:57:41, Martin Pieuchot wrote: > If it's acceptable performance-wise to do the check unconditionally > I believe that's the way to go. If not I'm a bit afraid of > introducing a flag/capability for a single driver. Do you know if > any other driver could use it? I haven't found specs of xen or vmware network drivers, therefore I can't say if those would have the same issue. One point for doing the check unconditionally is that it may guard against buggy hardware or buggy hypervisors (in cases the spec does not allow this). Since the observable error in our case was that sometimes TCP connections of other, unrelated VM hosts were aborted with TCP RSTs, such bugs are very difficult to find if they are not triggered often. I don't have a setup myself where I could do meaningful performance tests. If anyone has a setup where he can easily do such tests, it would be nice if he could test if removing the "(ifp->if_flags & IFF_PROMISC)" check in ether_input() makes any difference. Otherwise, I can try to do some performance tests at work, but that may take a while.