first-stage mount: support using other avb_keys

This change allows specifying additional avb keys to verify a fstab
entry. It can be used together with the original 'avb' flag. When both
'avb' and 'avb_keys' are present, it will try to use avb_keys to verify
this partition and extract the AVB descriptor from the end of it first.
When avb_key fails, it falls back to searching the AVB descriptor in the
built-in /vbmeta (and its chained partitions) with the matched partition
name.

An example of a fstab file:

system  /system  ext4  ro,barrier=1  wait,slotselect,avb=vbmeta,logical,first_stage_mount,avb_keys=/avb/gsi.avbpubkey
vendor  /vendor  ext4  ro,barrier=1  wait,slotselect,avb,logical,first_stage_mount

The overhead of adding an additional 'avb_keys' should not be significant,
as the typical size of a AVB Hashtree descriptor for /system is usually
less than 1000 bytes. e.g., on crosshatch, it's about 600 bytes, which
takes less than 1 millisecond for the following call to return failure.

   auto avb_standalone_handle = AvbHandle::LoadAndVerifyVbmeta(*fstab_entry);

We also checked the time spent on init's first stage on crosshatch, with the
following CL to set ro.boottime.init.first_stage. The testing result
shows no significant difference between them as well.

https://android-review.googlesource.com/c/platform/system/core/+/934536

With an additional avb_keys entry for /system
    [ro.boottime.init.first_stage]: [728]
    [ro.boottime.init.first_stage]: [720]
    [ro.boottime.init.first_stage]: [722]

Without an additional avb_keys entry for /system
    [ro.boottime.init.first_stage]: [730]
    [ro.boottime.init.first_stage]: [728]
    [ro.boottime.init.first_stage]: [725]

Bug: 124491153
Test: boot a device with above fstab settings

Change-Id: I0c81f816efb0dd40c93da2df304f2e215df9d105
Merged-In: I0c81f816efb0dd40c93da2df304f2e215df9d105
(cherry picked from commit a0f8b05d913855e3d8e9836f124fc9fdc755d450)

0 files changed, 0 insertions, 0 deletions