If you have paid attention to the system update log of mobile phone manufacturers, you will probably find that "fix vulnerabilities" is a word that will appear at high frequency. For friends who often pay attention to technology information, they should be so familiar that they are no longer familiar with news such as "XX company was exposed to have loopholes in XX software, which has caused XX people or devices to be affected."
Previously, this summer, the Internet security team from Google ProjectZero discovered multiple vulnerabilities from ARM Mali GPU. It seems that this is just an ordinary little thing in the field of cybersecurity, but it caused quite a stir a few months later.
days ago, in the latest blog released by the ProjectZero team, the finger was pointed at Android mobile phone manufacturers, and the words severely condemned these manufacturers' lazy behavior, among which even Google's own Pixel series models were not spared. The reason is actually very simple, so Android phone manufacturers do not take this series of loopholes seriously and are "sneering" in security updates.
Previously, the ProjectZero team successively discovered 5 vulnerabilities regarding Mali GPU in the ARM processor, among which the vulnerability numbered CVE-2022-36449 can allow non-privileged users to obtain write permissions to read-only memory . In the words of relevant researchers, successfully exploiting the vulnerability can allow an attacker to gain permission to execute native code, thereby gaining full access to the system, and bypassing Android's permission model to allow wider access to user data.
After receiving a vulnerability report from ProjectZero, ARM fixed these problems between July and August this year, issued security notices, and released the fixed source code. However, after ARM did what it should have done, mobile phone manufacturers were almost indifferent. The Project Zero team recently said that a few months after ARM fixed these vulnerabilities, their use of test devices equipped with Mali GPUs will still be affected by these problems. CVE-2022-36449 was not mentioned in the security announcement of almost any mobile phone manufacturer.
You should know that the CVE-2022-36449 vulnerability affects ARM's past three generations of Mali GPU architectures (Midgard, Bifrost, and Valhall), which covers the current Google Pixel 7 series, which can be traced back to 2016's Samsung Galaxy S7. In addition to Qualcomm, which uses its own GPU, other chip manufacturers supplying to Android phone manufacturers are involved. In other words, almost every Android phone manufacturer may have millions of affected devices.
In this way, isn’t this incident the Android mobile phone manufacturer treating the security of user devices as a joke? But in fact, Google is probably helpless. Currently, the security patch update for the Android system is based on monthly units, and the monthly security update for Android is also publicly released. However, Android phone manufacturers also have something to say. Monthly security updates are updates, but applying security updates to their own products is another matter.
In fact, system updates have always been a pain point in the Android ecosystem. The core reason is that compared with the closed Apple iOS system, there are much more participants in the Android camp. This is not only the advantage of Android being able to quickly unfold back then, but also the problem of restricting Android models to be timely updated today. Putting aside the developer adaptation application issues that both parties have to face, the Android camp has three parties in system updates, including Google, chip manufacturers, and mobile phone manufacturers, and the product lines of the latter two are quite complex, which also makes it much more difficult to update the Android version than iOS.
Although Google began to improve the system update speed of Android models many years ago, starting from Android 8, the newly added Project Treble separates the hardware driver from the system. From then on, mobile phone manufacturers can push new Android versions separately for mobile phones without re-adapting the driver. Project Mainline introduced in Android 10 modularizes system functions, allowing upstream suppliers to provide specific functional updates in a more detailed manner.
Sony drew a flow chart of Android system upgrade after Android 8 was released, and emphasized that Project Treble can reduce the process of system upgrade push by another 3-4 steps. But what they didn't tell the user is that even with these few steps, the process of updating the Android system is still very complicated. Take this ARM driver as an example. After ARM has completed vulnerability repair and disclosed the source code, mobile phone manufacturers cannot repair it as simply as we receive system OTA updates, but need to debug the driver to adapt to the ROM they have modified.
After all, Project Treble only allows mobile phone manufacturers to push new Android versions separately for their phones without re-adapting the driver, but this time it was the driver problem. Involving the underlying functions such as GPU driver, Android mobile phone manufacturers need to debug BSP (board-level support package). This is because the HAL (hardware abstraction) layer of the Android system needs to load BootLoader, and loading BootLoader depends on BSP. But it should be noted that the parameters of each hardware in HAL are very important trade secrets, so it also causes HAL to often exist in User Space, not in the kernel.
What’s even more regrettable is that in the Project Treble expansion project that decouples hardware drivers and systems in , Google chose to cooperate with Qualcomm instead of MediaTek . Project Treble's "no traceability principle" can only affect Qualcomm's Snapdragon mobile platform at present. For this reason, Qualcomm has developed its own universal system image system "QSSI", which can be compatible with different SoCs with Google's AOSPGSI. In other words, if there was a vulnerability in the Adreno GPU of Qualcomm SoC this time, the situation might be much better.
In addition, even the same model often has different versions. For example, Samsung 's Galaxy S series uses Qualcomm Snapdragon platform in China, Japan, the United States and South America, but in Europe and South Korea, they use their own Exynos main control. Coupled with the existence of the operator's customized version, just one device is enough to make the operation and maintenance team of the mobile phone manufacturer in a mess, not to mention that the Mali GPU has affected the products in the past five years, and such a large scale is enough to make the mobile phone manufacturer feel desperate.
So it can only be said that such a huge workload forced mobile phone manufacturers to choose to "show off". If you want to prevent similar incidents from happening again, it is only for Google to strengthen cooperation with ARM to follow Qualcomm to build its own universal mirroring system to speed up the deployment of updates.
