Split fsverity_init in two phases.
First load the verified keys, and then only lock the keyring after apexd
has run. This is in preperation for on-device signing, which will need
to add another key to the fs-verity keyring before it's locked.
Note that I've moved loading of the verified keys up a bit; fsverity_init
used to load keys from Keymaster, but it currently doesn't, so there's
no need to wait for it.
Bug: 165630556
Test: boot, cat /proc/keys
Change-Id: I077673575ae3dafcf3126d8c544fe7f8d34c0225
diff --git a/rootdir/init.rc b/rootdir/init.rc
index 52ba921..5a816c6 100644
--- a/rootdir/init.rc
+++ b/rootdir/init.rc
@@ -585,6 +585,9 @@
# HALs required before storage encryption can get unlocked (FBE/FDE)
class_start early_hal
+ # Load trusted keys from dm-verity protected partitions
+ exec -- /system/bin/fsverity_init --load-verified-keys
+
on post-fs-data
mark_post_data
@@ -826,6 +829,9 @@
wait_for_prop apexd.status activated
perform_apex_config
+ # Lock the fs-verity keyring, so no more keys can be added
+ exec -- /system/bin/fsverity_init --lock
+
# After apexes are mounted, tell keymaster early boot has ended, so it will
# stop allowing use of early-boot keys
exec - system system -- /system/bin/vdc keymaster early-boot-ended
@@ -1007,9 +1013,6 @@
class_start core
- # Requires keystore (currently a core service) to be ready first.
- exec -- /system/bin/fsverity_init
-
on nonencrypted
class_start main
class_start late_start