At Google I/O this year, we saw the announcement that Android O would bring a new change to the platform called Project Treble. When first explained, Google talked about how it is separating the vendor interface so that chip makers (like Qualcomm) don’t have to rewrite their code for the chips on the market each time there’s a new version of Android released. The goal here is to make the update process quicker and cheaper for companies working on this stuff.
While there is some inherent security benefits to getting these updates to devices faster, Project Treble goes beyond that to actually make our devices more secure as well. Since Project Treble is removing the vendor implementation from the Android framework, it will make things much more difficult for malicious code to attack and exploit the vendor interface.
Google explains this change by first describing how a HAL (Hardware Abstraction Layer) works. This provides an interface between both the device-agnostic code and the device-specific hardware we have inside our phones. With how things are right now without Project Treble, running HALs in-process means that it needs access to all of the permissions required by each in-process HAL. And this includes direct access to the kernel drivers as well, and also permissions required to other in-process HALs as well.
So what we have means that we have over-privileged processes and HALs that end up having access to permissions and hardware they shouldn’t. When we separate these things with Project Treble, we’re moving HALs into their own processes (as demonstrated in the featured image of this article). This generally results in an increase in IPC overhead between the client process and the HAL, but there have been some improvements made to the binder driver that makes all of this practical by improving performance for each transaction.
Read more at the Android Developers Blog!
from xda-developers http://ift.tt/2uCUwCd
via IFTTT
Aucun commentaire:
Enregistrer un commentaire