|author||Nick Bray <email@example.com>||Tue Jan 02 14:52:10 2018 -0800|
|committer||Nick Bray <firstname.lastname@example.org>||Thu Jan 25 10:35:48 2018 -0800|
Build AVB host test inside Trusty build. Bug: 70807715 Change-Id: Ifac3747f616b52d0a23e37de372f36ca26d51475
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.