Secure code enforcement issues
Remember: if we don't fix these issues the government will step in. In this case I think this may not be a bad thing.
What I have seen while working with large organizations, especially SoC vendors:
1. Code is considered a money pit.
2. Getting the code out in time is more important than quality.
3. Huge sections of code are zealously guarded. Try getting access to BRC WiFi code for their WiFi chips.
4. A flawed view of Performance trumps integer overflow/underflow, null pointer checks, buffer size checks, return value checks. A good CPU can perform these checks with no measurable impact on performance but ...
5. Static code analysis is generally turned off, especially for kernel and driver level code because software engineers get too many warnings (go figure). In one cellular modem company they turned off Klockwork static code analysis as it was giving too many warnings. In another they would not use it as people were UPSET that their code was being flagged. So it was turned off.
What Google can do is easier said than done:
1. Require all drivers go to through third-party code inspection (Samsung and others may not trust Google).
2. Require all driver vendors to submit static code analysis and other code inspection summaries
3. Provide a timeline for delivering fixes to Google.
4. Go public with the issues if the code is not fixed according to schedule.
5. The cell-phone manufacturers deliver a plan to deliver the fixes on time
6. Stick to the plan.
Then do the same for other critical code.
Problems? Asking Samsung, Qualcomm, and others to do anything is difficult (as in the Japanese way of saying something is difficult). Samsung, after all is the biggest company in S. Korea.
Biting the hand that feeds IT
