Re: xennet input processing and mac filtering

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Wed, Aug 28, 2024 at 12:43:39PM -0400, Greg Troxel wrote:
> mlelstv%serpens.de@localhost (Michael van Elst) writes:
> 
> > ether_input did (and still does) check if the packet is neither
> > multi-/broadcast nor for its own address and then marks the packets
> > as M_PROMISC.
> >
> >                 if ((m->m_flags & (M_BCAST|M_MCAST)) == 0 &&
> >                     (ifp->if_flags & IFF_PROMISC) != 0 &&
> >                     memcmp(LLADDR(ifp->if_sadl), eh->ether_dhost,
> >                            ETHER_ADDR_LEN) != 0) {
> >                         m->m_flags |= M_PROMISC;
> >                 }
> >
> > If M_PROMISC is set, the packet filter is skipped (?) and if it isn't
> > consumed by agr(4), vlan(4), carp(4) or pppoe(4), then the packet
> > is dropped later.
> >
> > But the check above only takes place when the interface is
> > in promiscous mode. Without promiscous mode, the code assumes
> > that all packets are actually for the machine.
> 
> That makes sense: there's a (not really well documented, perhaps) rule
> that interfaces must not inject non-matching unicast packets unless
> IFF_PROMISC.  Most drivers ensure this by hardware filtering, but xennet
> does not.
> 
> I see two possible fixes:
> 
>   in xennet, set IFF_PROMISC because the required mac filtering does not
>   happen
> 
>   in xennet, implement the filter that would been done in hardware,
>   basically in the receive path
> 
>     if ( not IFF_PROMISC and not (dst-ether matches ours) )
>       drop packet
> 
> 
> To see if this would fix the issue, someone could run tcpdump on the
> machine that responds when it shouldn't (after clearing the bridge
> cache).

I don't think we should set IFF_PROMISC; better to check the dst address
in the receive path.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--