3 ms·
On the point about riddled with bugs, the Qualcomm proprietary drivers absolutely are riddled with them. Even in their closed source and proprietary incarnation
by g_p 6y ago
On the point about riddled with bugs, the Qualcomm proprietary drivers absolutely are riddled with them. Even in their closed source and proprietary incarnation, take a skim through Google's monthly android security bulletins, specifically for the Qualcomm closed source components.
It's a long time since I did it, but I analysed the frequency and severity of identified vulnerabilities, looking at QCOM open and closed components... The results were fairly easy to predict and guess - the closed components had many more critical vulnerabilities, occuring at a far greater rate.
One reason Qualcomm wants to keep these closed is because of IP and the fact they often buy in third party IP (especially in imaging for example). The other reason is because they sell their proprietary userspace drivers to manufacturers as a "board support package", and they need to select the length of time they want updates for. In the old days before treble, when Google changed the HAL every release of android, this meant not being able to run using the old binaries, or having to write shim drivers to wrap old (closed, but exported) function calls with the new expected ones.
Post-Treble, the Swiss cheese nature of their driver code means OEMs need these updates to avoid their phones being compromised, ensuring further recurring revenue.
The best thing that could happen for Android security would be the opening of the entire Qualcomm userspace drivers, so they could be maintained by some competent developers, and eventually unified into an equivalent project akin to the mainline kernel, so that common code could be shared between generations, and therefore security patches can be applied to past devices' components.
And then the next best thing would be for QCOM to open source their modem and RIL (Radio interface layer), because both of those are vulnerability ridden messes of legacy code - I believe their radio baseband firmware is compiled using an utterly ancient compiler still, and lacks even basic secure coding principles. Occasionally you'll see some black box vulnerability research looking into these basebands and they tend to validate the above findings quite nicely.
- an_opabinia 6y agoWhile most people probably agree that the full open sourcing is the best for the consumer, eventually somebody needs to be paid to do the work. It's easy to say in hindsight where Android is massively successful, Google will someday allocate resources to recreate Qualcomm, from scratch, avoid patent issues like the consortia did with VC1, and expire the SoC industry. However that seems hard, also Apple has tried this and still hasn't finished an alternative to Qualcomm. Imagine it was 2006, when there was no one successful to copy. Even if Google were as rich then as it is today, but had the knowledge that Android was definitely going to be a hit, it would definitely not become a phone SoC company - neither did Microsoft nor Blackberry (did Nokia? I honestly don't know). They had the same conviction then in its success, so it didn't matter how much foresight about security issues affecting millions of people there would have been. In any circumstance, they would have not given the kit-and-kaboodle away for free in open source. They'd feel, much like Qualcomm feels today, that they designed something original. Oh, and so now it cannot be shared. Qualcomm got there first and sells this thing, that's the simplest reason they will never open source. They could achieve all your goals in a difference of execution, it's got nothing to do with the license of their source code. People have written secure closed source software. For me, there's an important difference between Linus Torvalds copying Unix to make Linux and some giant company copying some other giant company's stuff. Everyone is dancing around the fact that the two are not equivalent and pretending that they are. Someone eventually has to write original drivers that are good, for complex hardware. That person or entity has to get paid somehow. We're being really naive if we just assume that Google, an advertising company that in recent history never starts something unless there is already ample market success to follow (or displace), would do a good job, just because its engineers are highly paid, have lots of time and do algorithms questions well.
- cycloptic 6y ago>eventually somebody needs to be paid to do the work >That person or entity has to get paid somehow In my experience, it is very hard to get companies to even admit what the real cost of open sourcing something like this is. Lots of them just don't even want to talk about it or show their estimates at all, they just say "we will never open source" like Qualcomm does and the conversation goes nowhere. Even if the price is very high and it takes many years, we still need to start somewhere. Then the industry as a whole can chip away at it slowly, because even very slow progress is better than nothing at all. And what's even worse than no progress is if we just give up and sit around waiting for some other company like Google or Apple to foot 100% of the bill to redo all the work over again from scratch.
- g_p 6y agoI think part of the unwillingness is due to the incorporation of external third party IP they realise they have no real prospect of being able to get a license to open source. In some areas like imaging this always seemed to be particularly problematic - from memory, some of the early "Sony Mobile" Android devices (thinking Xperia Z, Z2 era, etc.) actually used TrustZone DRM to prevent use of certain imaging libraries they had "licensed in", in order to discourage/prevent reverse engineering of them by users that had unlocked the bootloader and thus would likely have root access to facilitate meddling with them. I believe that people eventually removed the TrustZone checks, but the intent was clear. This isn't Qualcomm directly though, but I imagine it shows part of the root of the challenge here.
- pabs3 6y agoThe Freedreno project did some reverse engineering of Qualcomm userspace GPU drivers, so now those GPUs have a free implementation. https://en.wikipedia.org/wiki/Free_and_open-source_graphics_device_driver#Qualcomm https://en.wikipedia.org/wiki/Free_and_open-source_graphics_... Are there other Qualcomm userspace drivers that need to be freed?
- g_p 6y agoYes, the Freedreno work is a really good start, and an admirable one at that which has reached fruition! I think there's quite a lot of closed userspace drivers that need (or would benefit from being) freed - I don't have a list to hand, but a quick look inside the /vendor partition (and directory) of a recent phone will give an idea of the closed userspace drivers being shipped on devices.