|author||Rajesh Nyamagoud <email@example.com>||Tue Mar 10 17:07:48 2020 -0700|
|committer||Rajesh Nyamagoud <firstname.lastname@example.org>||Tue Mar 10 17:07:48 2020 -0700|
Switch from manifest.c to manifest.json config Bug: 130560272 Change-Id: Ic89f041ad4d2afb5eedc1bbc81f73c0b36e492e3
The AVB (Android Verified Boot) resource manager is intended to provide tamper proof storage for data used by libavb. This includes the verified boot lock state, stored rollback index values, and ATX (Android Things eXtension) permanent attributes.
Rollback indexes are strictly increasing, and any request to write a value to a rollback index that is smaller than the existing value will fail. A mask (0xF000) is used to map a rollback index to a file, and a file may contain a maximum of 32 rollback indexes. For example, 0xF01F and 0x0001 are valid values for the rollback index, but 0x10000 and 0x0020 are not.
If the lock state is 1, or LOCKED, then verification errors are fatal, and booting MUST fail. If the lock state is 0, or UNLOCKED, the device may boot even when verification fails. When the device changes lock state, all stored rollback indexes are cleared.
A hash of the attributes MUST be stored in write-once fuses. Once this is written, any subsequent requests to write it will fail. Attributes are stored as an opaque buffer and parsed by the bootloader.
Once the AVB resource manager receives a LOCK_BOOT_STATE request, all requests to write to resources will fail until the next reboot. This should be called after libavb has acquired all necessary resources, and before the bootloader passes control to the HLOS. This prevents a compromised HLOS from tampering with AVB resources.
Since libavb is executed by the bootloader, the non-secure side API that makes requests to the AVB resource manager is located here.