Please see our release notes: https://grapheneos.org/releases#2022121400 https://grapheneos.org/releases#2022121400 > kernel (Pixel 7, Pixel 7 Pro): update Ma

Please see our release notes: https://grapheneos.org/releases#2022121400 https://grapheneos.org/releases#2022121400 > kernel (Pixel 7, Pixel 7 Pro): update Mali GPU driver to r38p1 along with other changes included in the QPR2 Beta 1 including a bunch of security fixes previously neglected upstream (GrapheneOS will continue applying further updates downstream) Our December 14th release was the release fixing this vulnerability and a bunch of others based on the Android 13 QPR2 Beta 1 release on December 12th which included these fixes. The January release of AOSP and the stock Pixel OS also included the security patch backports without including the update to r38p1. The update to r38p1 is nice to have since it fixes more bugs than the security bugs and has other improvements, so it's nice that we were able to ship it early but it's not really a security feature. This isn't like the Linux kernel where there are an enormous number of changes and no serious attempt at determining which ones are security bugs. ARM does a good job determining which are security bugs and making security patches available separately. Unfortunately, ARM is not very friendly towards people building on their platform that are not partnered with them. They don't make the standalone security patches publicly available, even after a delay. It's possible they see making the patches available separately as helpful to attackers but that's a bit ridiculous because the code is available either way and it doesn't take long to identify the security patches which are one of the main things being done in the releases. If ARM made the standalone security patches public available, we could get them to our stable channel within days of release instead of needing to wait for their partners like Google or Samsung to do their own releases and publish the patches. It would be very helpful to us if an ARM partner collaborated with us since we would be able to ship these fixes faster. The reason we can't simply upgrade to the new major releases of the driver immediately is because there are thousands of lines of changes to the kernel driver for the Tensor SoC with many invasive optimizations switching to finer grained locking across the driver, adding quality of service for GPU commands, etc. They made substantial changes to the driver and seemingly also the firmware/hardware to an extent, although likely just in between the actual GPU and the OS where they handle IOMMU, quality of service, etc. If they had a barely modified ARM Mali GPU and driver, we could easily update to each new major release in days, but that's not the case. We could do that on another device without so many changes to the driver though. It's entirely device specific. ARM provides a base for vendors to build on and how much they optimize/improve things downstream varies a lot. Google decided to do a ton of downstream optimization for the Pixel 7 GPU. They decided to focus on the GPU with that generation and let the CPU get neglected, which they'll almost certainly fix next year. Part of the initial growing pains for Tensor has been that they released the Pixel 6 with a great CPU but weak GPU and then the Pixel 7 with a great GPU but outdated CPU. These delays with Mali patches are another example, although other Android vendors almost all did worse not better.