Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 3b68bf2d authored by Martijn Coenen's avatar Martijn Coenen
Browse files

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
parent b0db51d3

rootdir/init.rc

+6 −3
Original line number Diff line number Diff line
@@ -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