From 3b68bf2d347fdba75ceae43708ccf037f75beff8 Mon Sep 17 00:00:00 2001 From: Martijn Coenen Date: Mon, 30 Nov 2020 10:05:40 +0100 Subject: [PATCH] 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 --- rootdir/init.rc | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/rootdir/init.rc b/rootdir/init.rc index 52ba9210f..5a816c6b8 100644 --- a/rootdir/init.rc +++ b/rootdir/init.rc @@ -585,6 +585,9 @@ on late-fs # 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 @@ on post-fs-data 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 @@ on boot 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