Strictly-Enforced Verified Boot with Error Correction to Come with Android 7.0 Nougat

As the inevitable release of Android 7.0 Nougat comes closer, more and more details are made privy to users and developers alike. The latest bit of info involves dm-verity and would likely be of interest to a decent chunk of our readers here at XDA-Developers.

Back in Android 4.4 Kitkat, Google introduced what is called “verified boot”. This feature was made available via the device-mapper-verity kernel feature, in an effort to provide a means to carry out integrity checks on block devices and prevent malware from holding onto root privileges through a reboot. The end result was that users can be confident that the device was in the same state as they last used it with the system partition protected and unmodified. You can read more about dm-verity and verified boot over here.

With the release of Android 6.0 Marshmallow, Android warned the user upon boot if something was amiss. But beyond that, the OS did not take any steps, and left the onus of protection on the end user. But with Android 7.0 Nougat update, Android will allow actions beyond the simple intimation. Verified boot will now be strictly enforcing, and devices with a corrupt boot image or verified partition will not boot at all…or boot in “limited capacity” with user consent. The extent of this limitation is not mentioned, so we can just speculate on what this means.

The results of this strict checking are plenty. For instance, security is now much more pronounced on devices, as it no longer depends on user apathy to take control back from malicious situation. The average user may not realize what is the best course of action for his device (or even realize that his device is compromised in the first place), so Google believes it’s a good idea to take control away from the user. But on the flip side… well, control is being taken away, meaning that those that do understand what is happening have little power to affect the course of actions, especially if they have no other option. The blog post even goes on to mention another result: “Such strict checking, though, means that non-malicious data corruption, which previously would be less visible, could now start affecting process functionality more.”

Does this affect root, mods, custom ROMs and kernels? It does, but to a limited subset of these modifications for a number of devices. Most devices typically need an unlocked bootloader to allow any and all modifications outside of OEM changes. For such devices, where the bootloader will be unlocked, these new changes should not be anymore of a hindrance than what it is now. But, there are several devices which obtain root and custom ROMs on a locked bootloader (mostly because it is more difficult to unlock the bootloader than it is to root it through exploits). For these devices and for those that have a rich history of not being developer-friendly, this makes the job all the more difficult.

We will update you with more details on this and other developments as we learn about them. For now, it’s best to wait and see how these systems behave, and what their real impact is like.

from xda-developers http://ift.tt/29OPPHV
via IFTTT