Chainfire：SuperSU v2.82 SR1 (BETA) released
Chainfire：SuperSU v2.82 SR1 (BETA) released
Before I go into details of this release, some have questioned whether this G+ account and the Chainfire developer account on Play are being controlled by CCMT. They aren't, it still me - Chainfire - writing this, and I am still in full control of these accounts.
This update focuses primarily on changes introduced by the latest security patches to Nougat and O Preview. I've noticed some people posting everything is fine and old versions of SuperSU already work great, but these are probably users of the Nexus 5X and 6P. All the interesting (and breaking) stuff is premiering on the Pixels! Those changes may not be coming to the 5X/6P soon or even at all (or they may be in ODP4, who knows?).
I'll start with some other changes, and end with everything O.
Android 5.1 and older
A small number of users have reported dalvik-cache rebuilds on every boot on 5.1 with v2.82. We have not been able to reproduce this on our 5.x devices. If you're seeing this issue, please come to the BETA thread (linked below) and help us figure out the problem.
There have been some minor changes to the ZIP that makes it compatible with the very latest firmwares of some Huawei devices that were not previously compatible. We are aware that is still doesn't work for some other Huawei devices/firmwares. If you are using a Huawei that is currently not supported by SuperSU, please come to the BETA thread (linked below) and help us correct the issue. Please include information about your device and firmware version in your report.
Samsung Nougat and encryption
Samsung has recently made some changes on how encryption works on their Nougat firmwares that could ultimately cause full bricks for root users not paying attention. This appears to be a security measure (good) that is still a little rough on the edges (bad).
You can read the full details about the changes and my experiments with it here: https://forum.xda-developers.com/showpost.php?p=72204306&postcount=978
My personal advice for the moment is, if you're going to run rooted on a Samsung device with Nougat, format /data before flashing SuperSU, or otherwise ensure /data is not encrypted.
From v2.82-SR1 onwards, on Samsung devices running Android Nougat 7.0+, SuperSU will detect an unencrypted /data partition (which is always the case directly after a format) and by default attempt to fully disable encryption, to prevent the device from re-encrypting /data next boot. Obviously this means reduced security for your files, but also a significantly reduced risk of ending up with a brick. For advanced users there are flags to control this behavior.
Android Verified Boot signing
On the Pixels with the May security update or newer (and probably many devices and firmwares in the future), boot images are required to be signed for Android Verified Boot. I have detailed the procedure and created a flashable ZIP that does this on-device here: https://forum.xda-developers.com/android/software-hacking/signing-boot-images-android-verified-t3600606
From v2.82-SR1 onwards, the SuperSU ZIP will automatically sign the patched boot image, if the original boot image is also signed. Please note that if you first flash an unsigned image (like a custom kernel install that doesn't sign the new image), then SuperSU will not sign the output image; this is because SuperSU cannot know if your device needs a signed image or not, and just signing all images might create problems for other devices, so signing the output is based on whether the input was signed.
For advanced users there are flags to control this behavior. For the security paranoid, you can even provide your own signing keys rather than using SuperSU's default ones.
I am very curious if we will run into a device that does have AVB signing and currently works with an unsigned SuperSU image but not with a signed one.
Noteworthy caveat: signing only works if your /system partition is intact.
Android O - SELinux policy rules
As usual, a major new Android version brings some SELinux policy changes. These were very minor and only have to do with the introduction of two new security contexts: untrusted_v2_app and untrusted_app_25. Most of these changes were already implemented in v2.79-SR4, but two lines were added for v2.82-SR1 to complete the set.
Android O - Split policies
On the Pixel, O increases separation between Google provided system parts (Android), and manufacturer parts (such as drivers and SoC-specific components). Ultimately this will make it easier for (future) older devices to run newer Android versions. For more information about that, read this blog post about Project Treble: https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html
For SELinux policies this means that some of the policies are loaded from the boot image or /system partition, and some are loaded from the /vendor partition. These are merged at first boot and cached for future boots.
As SuperSU needs to modify SELinux policies for it to be able to run, it pre-merges the two sets of policies at ZIP flash time, makes the required modifications, and forces this merged policy to be loaded at boot instead.
Noteworthy caveat: merging only works if your /system and /vendor partitions are intact.
Android O - lz4 compressed kernel binary
On the Pixel, Google is using lz4 compression for the kernel binary, so support for that (but not for lz4 compressed ramdisks) has been added to SuperSU. I assume this is part of their efforts (mentioned elsewhere) to improve boot-up performance on the Pixel series.
I don't think we've seen lz4 compression employed by official Google images before ODP2.
Android O - fstab/dtb
On the Pixel, it appears the rootfs fstab has been completely removed, in favor of automatic partition detection and dtb-based fstab.
The system and vendor partitions are both required to be mounted early now that the policies have been split in two. The system partition was already pre-mounted by the kernel on the Pixel series (and other devices that have the root directory inside the system partition rather than in the boot image ramdisk), but now the mounting of the vendor partition has also moved to earlier in the boot sequence.
The fstab entry for vendor has now been moved to the dtb (device-tree blob) section of the kernel image. To me this is slightly odd as the device-tree is supposed to be OS independent, but then again, it is contained inside a very OS-specific boot image...
To cope with the dtb-based fstab, SuperSU (sukernel specifically) has gained functionality to extract, modify, repack and replace the dtb.
Android O - boot image size
When the Pixel was first released, there was a lot of space available in the boot image. Unfortunately, Google's stock boot image has grown significantly since then. This hardly leaves room for all the files SuperSU wants to include.
I could significantly reduce those files by disabling some features (in-ramdisk backup of modified files and factory-reset survival for example) but I would rather not.
As such I have had to implement some smart coding to reduce the files' footprint by pulling files into the ramdisk from /system dynamically at boot time rather than including them at ZIP flash time.
While this is sufficient for now, we'll have to see how this works out when O-compatible TWRP builds and custom kernels become available (both of which also need to go into the same limited boot image space).
We could reduce the used space by eliminating unused dtb parts, but this would create a very device-specific solution rather than a generic solution I always aim to create. While you may argue that currently most of this only affects the Pixel (XL) anyway, several devices will be released shortly that are using the same setup.
Android O - suinit
The above combined have required significant changes to the suinit binary. It has to handle the new mounting sequence as well as creating the ramdisk dynamically.
All in all, expressed in lines of code added or changed the number is not impressive at all (rather disappointing really), but figuring out all of the above and implementing the fixes is very time-consuming. It is slow (and frustrating) to debug this part of the boot process; especially as proper sources are not yet available and you're mostly stabbing in the dark, hoping to hit something that sheds some light on what is going on.
Noteworthy caveat: for the rare advanced user who uses KEEPVERITY functionality, note that keeping dm-verity enabled on the Pixel on O Preview is currently only supported for the vendor partition, not for the system partition. The system partition is not modified in any way, but we can no longer rely on the real init to enable dm-verity for the system partition, so suinit will have to do this, and the code for that is not yet written. Previously we got the original init to do this using fstab, but the dtb-based fstab is too limited to get this to work.
As with all SR releases, you are supposed to update them by flashing the ZIP, not by installing the APK.
BETA discussion thread on XDA:
Instructions for flashing this ZIP with TWRP on Pixel (XL) with ODP1/2/3:
- ZIP: Detect AVB signature on input boot image, and sign output image accordingly (force with SIGNBOOTIMAGE, custom keys in /tmp/avb)
- ZIP: Samsung/7.0+: if /data is not currently encrypted, disable encryption (unless KEEPFORCEENCRYPT or REMOVEENCRYPTABLE are set)
- ZIP: Detect TWRP UI slot switch (Pixel/XL: 3.1.0-RC2+)
- ZIP: Further improve /system device detection
- ZIP: Support compiling sepolicy from split CILs
- ZIP: Kernel patch: support LZ4 compressed kernels (new format only)
- ZIP: Mount /vendor
- ZIP: Add /vendor/lib to LD_LIBRARY_PATH
- ZIP: Initial Pixel+ODP2 support
- ZIP+APK: Fixes in boot partition detection
- sukernel: Allow cpio-add of 0-byte files
- sukernel: Add dtb (in-kernel only) related features
- suinit: Improve logging
- suinit: Support pre-mounting /system and /system_root (ODP2+)
- sukernel+suinit+ZIP: Reduce system_root footprint by dynamically importing entries at boot
- supolicy: Adjustments for ODP3