As early as fsverity_init, the flag can only be static (thus
is_fixed_read_only). It is now a constant/false and will be flipped
during the ramp up at build time.
Bug: 290064770
Test: mma
Test: Inspect the generated code
Change-Id: I4bd1addb996705f6e6b9f75313bf22b9ecd3e11c
Now that fsverity_init is no longer used, it can be removed.
For more details, see https://r.android.com/2662658.
Bug: 290064770
Test: presubmit
Change-Id: I9a90a7141d708ea8aaeefc54288083ee5a0f52ff
The --load-extra-key option to 'fsverity_init' was only used by odsign,
and --lock was only used by init.rc. Since these uses have been
removed, remove the code that implemented these options as well.
Bug: 290064770
Test: presubmit
Change-Id: Iaad4b78926748f24dcaddecb27dc28e4c659a574
Since Android no longer uses fsverity builtin signatures, it's planned
to start configuring the kernel without
CONFIG_FS_VERITY_BUILTIN_SIGNATURES. Therefore, make fsverity_init
cleanly handle the case of CONFIG_FS_VERITY_BUILTIN_SIGNATURES being
disabled. Also document why fsverity_init still has to exist at all.
Bug: 290064770
Test: Booted Cuttlefish with android-mainline kernel with
CONFIG_FS_VERITY_BUILTIN_SIGNATURES disabled. Checked logcat for
message indicating that 'fsverity_init --load-verified-keys'
exited with status 0.
Change-Id: I0e232c9f4fb80f790ccafb03c10bb5dd5f24fe24
This reverts commit 3fc82ead6b because the
only user of libfsverity_init other than fsverity_init has been removed.
(Don't add "liblogwrap" back to shared_libs, as it isn't needed.)
Bug: 290064770
Test: presubmit
Change-Id: Ia5a0e60a16c1f88974ceb4500084b0c3773d3e43
There are use cases where fs-verity without signature is helpful. Relax
the restriction. Existing use cases (other than work-in-progress
features) of fs-verity in AOSP has been migrated to signature check in
userspace.
Bug: 249158715
Test: CtsAppSecurityHostTestCases:android.appsecurity.cts.ApkVerityInstallTest
Ignore-AOSP-First: Security implication requires some change in frameworks/base
Change-Id: I6b7d7143485ad304d4aa7e8a924d32d558540b92
Merged-In: I6b7d7143485ad304d4aa7e8a924d32d558540b92
This is needed to import some of the functionality into first stage
init.
Bug: 199914227
Test: build
Change-Id: I0a78f62b1957404d7fe78c79151a1620834ea3a1
When attempting to load a non-existent cert I got:
06-10 12:48:11.939 662 662 E fsverity_init: Failed to add key: Invalid argument
06-10 12:48:11.940 662 662 E fsverity_init: Failed to load key from stdin
06-10 12:48:11.941 648 648 I odsign : Added CompOs key to fs-verity keyring
Which looks like everything worked when nothing did.
Added more error checks on both sides.
Test: Presubmits
Test: Manual
Change-Id: Ib2b17ce75e58dafb0ad6905106e35b11b55e91d0
Soon we'll have a need for multiple fs-verity keys in the keyring; we
need a central place to manage the keys, as well as restrict the
keyring. fsverity_init makes most sense for this.
Allow fsverity_init to be called in 3 different ways:
--load-verified-keys: loads preloaded keys from trusted partitions
--load-extra-key: loads an additional key passed in from stdin; the key
name is given as an argument.
--lock: locks the keyring, and prevents new keys from being loaded
Bug: 165630556
Test: boot, cat /proc/keys/
Change-Id: I758e49a5c4229edc531d01ac2e8873a22a1da73e
Test: still see keys loaded from /product appears in /proc/keys
Test: Add X.509 DER cert files to keystore, see the key in
/proc/keys after reboot
Bug: 112038744
Change-Id: I08006d8befa69e4bf416a2bed9e1813725877147
