search

chenxiaolong / avbroot

Sign (and root) Android A/B OTAs with custom keys while preserving Android Verified Boot
GNU General Public License v3.0
499 stars 40 forks source link

Things that won't be implemented #185

Open chenxiaolong opened 11 months ago

chenxiaolong commented 11 months ago

This issue lists all features I've decided not to implement and the reasons why. It'll likely be updated over time.

Incremental OTAs

payload.bin only supports the bsdiff binary diff format and Google's puffin variation of it. Creating a direct diff of the old and new partition images is frequently infeasible or useless because it cannot efficiently handle the same data being moved to a different part of the file. For example, if the contents of media/bootanimation.zip inside product.img did not change in the new OTA, but was just relocated to a different offset, bsdiff likely won't account for that and will produce a large diff. In addition, the computation might not be possible at all: bsdiff requires enough RAM to hold 17x the size of the old image. Trying to directly diff the Pixel 7 Pro's 3 GiB stock product.img would require 51 GiB of RAM.

AOSP's delta_generator, the standard tool used for generating incremental OTAs, works around this by including parsers for the ext4, erofs, and squashfs filesystems. This way, it can compute diffs for individual files inside the image, regardless of the data offsets. The parsing of these filesystems is very hacky (which the AOSP folks themselves acknowledge) and only works on Linux. Implementing new filesystem parsers in avbroot is too complicated to be feasible.

For folks who really want to generate incremental OTAs, see avbroot-inc-ota. It requires building AOSP from source (100-200 GiB) for the delta_generator executable and only works on Linux. The incremental OTA generation process is incredibly slow. On an Intel i9-9900KS, generating an incremental OTA that upgrades to the same Android build (ie. empty diff) takes 3 minutes. Generating an incremental OTA for upgrading the stock Pixel OS from 13 -> 14 takes 45 minutes.

Packing OTAs ~or payload.bin~ from a directory of partition images

avbroot includes unpack and pack commands for many components, like AVB and boot images, but does not provide any way to pack a full OTA zip ~or payload.bin file~.

This is an intentional decision to make it more difficult for a user to accidentally brick their device. Having an avbroot ota pack command would make it very easy to include, for example, a boot.img that's not properly signed or a vendor_boot.img that doesn't contain the appropriate certificates to allow sideloading further OTA updates. If the user disabled the Allow OEM unlocking option, this would effectively cause a hard brick.

Folks who want to replace arbitrary partition images should use the --replace option for avbroot ota patch. The patch command guarantees that the boot image and OTA will be signed appropriately.

2024-09-15 update: Packing payload.bin was implemented in #331. For the reasons described above, packing OTAs is still not supported.

RSA 8192 keys

avbroot uses the RustCrypto suite of libraries, which currently do not support RSA 8192 keys. Even though AVB theoretically supports RSA 8192, it is not known to be used in any device's stock OS or custom OS images. RSA 4096 keys are recommended and are what the avbroot key generate-key command generates.

~Adding custom OTA key to system.img's system/etc/security/otacerts.zip~

~This is currently done by flashing a Magisk module instead of modifying the system partition directly. Although avbroot has the ability to properly rebuild and resign all the relevant AVB information, it does not have the ability to edit ext4/erofs filesystems. That is way too complicated to do and is out of scope for this project.~

2023-12-29 update: This was actually implemented! #225 #240 #244.

athanatos1 commented 10 months ago

May you also write a guide to incorporate KSU into kernel source code for novices? I would really like to try this method out but I do not know where to start with KSU.

EDIT: or better yet, since you are applying a patch with avbroot, can you incorporate KSU into the patching process for the kernel to simply things?

chenxiaolong commented 10 months ago

May you also write a guide to incorporate KSU into kernel source code for novices? I would really like to try this method out but I do not know where to start with KSU.

EDIT: or better yet, since you are applying a patch with avbroot, can you incorporate KSU into the patching process for the kernel to simply things?

The patching process avbroot does is only for the boot image. When using avbroot, for Magisk, the apk must already exist, and for KernelSU, the kernel must have already been built.

Modifying the kernel source code for KernelSU is outside of the scope of this project. Unfortunately, I'm not familiar with the process of doing that, so I don't have any suggestions for guides to follow.

athanatos1 commented 10 months ago

Thank you for responding back and understood. One last question: if my device firmware doesn't have a payload.bin and only has slot A, without b slot, can Avbroot still work? It only has all the .img files to flash via fastboot and folders metainf and firmware-update.

chenxiaolong commented 10 months ago

No problem!

if my device firmware doesn't have a payload.bin and only has slot A, without b slot, can Avbroot still work?

Sorry, unfortunately not. Avbroot is completely designed around the payload.bin A/B update format. It would take significant work to add support for other formats.

(A/B is technically not required, but for some reason, Google decided to only use payload.bin for A/B setups and not A-only.)