←back to thread

Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

(blog.exodusintel.com)
387 points pedro84 | 1 comments | 26 Jul 17 19:51 UTC | HN request time: 0.216s | source
Show context
thomastjeffery ◴[26 Jul 17 23:00 UTC] No.14861166[source]▶
Why does Broadcom insist on proprietary drivers?

How could it possibly be detrimental for Broadcom to have free software drivers?

This article is a poignant example that it is detrimental for them to continue to keep their drivers proprietary.

replies(6): >>14861174 #>>14861519 #>>14862058 #>>14863796 #>>14867469 #>>14871284 #
whowouldathunk ◴[26 Jul 17 23:01 UTC] No.14861174[source]▶
The drivers are probably pretty complicated and thus valuable IP.
replies(2): >>14861236 #>>14867384 #
thomastjeffery ◴[26 Jul 17 23:15 UTC] No.14861236[source]▶
I don't buy that.

Every wifi chipset has working drivers; therefore there is little to no value in Broadcom's driver as "IP".

Contrast that to the value of having a free driver that can receive security patches from anyone at any time.

replies(6): >>14861326 #>>14861646 #>>14862004 #>>14862013 #>>14862510 #>>14863716 #
1. hedora ◴[27 Jul 17 03:35 UTC] No.14862510[source]▶
I'd argue most wifi chipsets do not have working drivers, but I have an apparently high bar for "working": It has to stay authenticated to a given access point indefinitely, can't kernel panic or require reboots to switch to a new network, and needs to have competitive throughout and tail latencies under load.

Most wifi adapters fail at least one of these requirements under windows or linux.