On Fri, Aug 14, 2015 at 3:46 PM, Daniel Borkmann <dan...@iogearbox.net> wrote: > On 08/14/2015 09:27 PM, Willem de Bruijn wrote: > ... >>> >>> Btw, in case someone sets sock_flag(sk, SOCK_FILTER_LOCKED), >>> perhaps we should also apply it on fanout? >> >> >> Good point. With classic bpf, packet access control is fully >> enforced in per-socket filters, but playing with load balancing >> filters could allow an adversary to infer some information >> about the dropped packets*. With eBPF and maps, access >> is even more direct. Let's support locking of fanout filters in >> place. > > > Right, a process could share a map between the fanout lb filter > and actual sk filter, i.e. to look up how much actually passed > through on the later sk level filter, and use that information > in addition for its lb decisions. > >> I intend to test the existing socket flag. No need to add a >> separate flag for the fanout group, as far as I can see. > > > Agreed, should be okay.
Great. Thanks for the suggestion, Daniel! I'll send a v2 the three suggested changes in a minute. > > Thanks Willem! > >> (*) I noticed that a similar unintended effect also causes the >> PACKET_FANOUT_LB selftest to be flaky: filters on the >> sockets ensure that the test only reads expected packets. >> But, all traffic makes it through packet_rcv_fanout. Packets >> that are later dropped by sk_filter have already incremented >> rr_cur. Worst case, with 2 sockets and each accepted packet >> interleaved with a dropped packet, all packets are queued on >> only one socket. Test flakiness is fixed, e.g., by running in a >> private network namespace. The implementation behavior >> may be unexpected in other, production, environments. >> -- >> To unsubscribe from this list: send the line "unsubscribe netdev" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
