On Mon, Dec 5, 2016 at 12:09 PM, Hans Leidekker hans@codeweavers.com wrote:
On Mon, 2016-12-05 at 11:28 -0200, Bruno Jesus wrote:
You are trading correctness for performance, and even with this filter the getsockopt calls are probably too expensive. I guess this information should somehow be cached.
I agree with you, it is a tradeoff. The filter is fast because the patch reduces the scope of the test to only a few handful of packets that are probably broadcast addresses, only then it will check the broadcast flag and in the kernel this is very fast because judging by the kernel source code. Only if previous conditions are met it will check if it really was a broadcast address.
It's still a context switch. Couldn't there be more than a handful of broadcast packets?
A different approach would be to let it hit EACCES when sending and check for the error and only then do all tests, that would still work and still be only a handful of packets but then we could check for the broadcast address everytime without suffering from performance and getting perfect correctness. What do you think?
That would get rid of some the performance cost (more importantly it would no longer hurt the general case), but it would still require get/setsockopt calls for every broadcast packet.
Just as background: Old games used broadcast to help auto finding other players in the same network, I have seen a handful of network messaging programs that also did that to simplify file transfer by finding if the user is in the same network avoiding a server relay. Some games that use broadcast are Command & Conquer, Age of Empires and Worms 2. This is not something you do 100 times per second, eg C&C used a 3 second interval.
But none of these games are not affected by this bug. This bug is about a very particular case in the broadcast implementation of Windows that allows a broadcast without explicit SO_BROADCAST.
We have 2 case scenarios by using the EACCES approach:
1 - The socket is SOCK_RAW and that is why it was not allowed; 2 - The socket is UDP and SO_BROADCAST was not enabled.
The first is discarded as soon as we check the socket type, which uses SO_TYPE. Then we will check if the SO_BROADCAST was disabled and only then check the broadcast address. In other words, for every packet that hits EACCES (overly extremely rare) we will call SO_TYPE and then check the UDP stuff is required and if yes try resending the packet.
There won't be any performance hit in the standard socket usage (data sending using tcp/udp), only when EACCES happens that we will need to do something.