Previously, the boot process of microdroid was mostly implemented in the
init.rc file. microdroid_manager was started first in the background,
then apexd, apkdmverity, and zipfuse were executed in sequence. However,
in order to correctly implement the app payload verification scheme,
most of the early boot process has to be controlled by
microdroid_manager. Specifically, apkdmverity should be started "after"
the apk roothash is read from the instance disk by microdroid_manager.
As an alternative, we could let apkdmverity the read instance disk by
itself. However, this is undesirable because doing so requires multiple
processes - microdroid_manager and apkdmverity - have access to the
instance disk and more seriously the secret key to decrypt it.
Another alternative is to let microdroid_manager do the dm-verity
configuration which apkdmverity does. This also is considered
undesirable because then we would give the permissions for configuring
dm-verity devices to microdroid_manager which is a long-running daemon
process. Note that apkdmverity is not a daemon process.
This CL introduces a few number of changes which are required to let
microdroid_manager directly control the early boot process:
1) microdroid_manager is allowed to start the services apkdmverity and
zipfuse by using the `ctl.start` sysprop.
2) apkdmverity is allowed to use bootstrap bionic libraries as it is now
executed before APEXd activates the APEXes.
3) A new sysprop `microdroid_manager.apk_roothash` is added. It is
written by microdroid_manager and read by apkdmverity. It contains the
roothash read from the instance disk. This value is not a secret.
4) Another new sysprop `apex_config.done` is added. It is set by init
just after `perform_apex_config` and read by microdroid_manager.
Microdroid_manager uses this to wait until linker configuration is ready
so that it can execute app payloads with the config.
Bug: 193504400
Test: atest MicrodroidHostTestCases
Change-Id: If29ce17d7a6cb4859e8ceeffb321724e7f11bf82
