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.
Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
51–60 of 171 posts
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#52Earlier quoted context omitted.
Every GPU has working drivers, but optimizations within them can make huge differences in performance on the same hardware.
The driver 'optimizations' in GPUs tend to boil down to hand written replacements for unoptimal/broken shaders and API call sequences on a per application basis. I expect a network card to not 'interpret' my traffic in a similar way.
The way the drivers + backing architecture are built contains tons of IP and things that they would very much not want their competitors seeing.
Our team built our reputation and relationship on keeping that data separate and confidential despite working with just about every vendor out there.
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#53Earlier quoted context omitted.
What do you mean by C not having arrays?
They are a pointer and an offset with no validation of bounds. But that's OK: C is little more than a high level assembly.
C is full of undefined behavior, assembly is not.
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#54Earlier quoted context omitted.
Every GPU has working drivers, but optimizations within them can make huge differences in performance on the same hardware.
The driver 'optimizations' in GPUs tend to boil down to hand written replacements for unoptimal/broken shaders and API call sequences on a per application basis. I expect a network card to not 'interpret' my traffic in a similar way.
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#55Earlier quoted context omitted.
They only hijacked the radio chip, they didn't escalate to the main processor. One way of attacking would be to intercept someone's internet traffic, and redirect them to a different site (ie, instead of going to Google, you go to get-hacked which looks just like Google).
They intercept and modify packets to redirect to a web site they control. It exploits the main processor through the browser.
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#56Earlier quoted context omitted.
The drivers are probably pretty complicated and thus valuable IP.
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 .
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#57Earlier quoted context omitted.
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 .
Every GPU has working drivers, but optimizations within them can make huge differences in performance on the same hardware.
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#58Earlier quoted context omitted.
If a manufacturer makes and sells a gun that keeps going off in people's holsters and shooting people in the foot, the answer is not to say "it's the user's fault for not using it properly. I've shot myself in the foot hundreds of times and I don't blame the manufacturer". Or something. That analogy sounded better in my head than written down. The point is that IMO the blame lies squarely with the C language: it's a…
I shot myself in the foot yet I don't blame the manufacturer for not putting a safety on the gun since I'm the one that bought it with full knowledge of the caveats
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#59Earlier quoted context omitted.
which basically means don't use any wifi. I think at least 60% of all wi-fi chipsets are broadcom ones.
that seems pretty doable. on phones there's qualcomm chipsets, and on desktops/laptops there's atheros, intel, and realtek (of the vendors i know of).
And this is preferable to a software fix.
Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets
#60Why 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.
One theory I've seen bandied about related to GPU drivers is that it's harder for your competitors to notice you're infringing on their patents if you don't ship your source code.