This removes the need to query for and call find on all IRPCs.
Bug: 312427637
Test: atest -p --include-subdirs system/security/keystore2
Change-Id: I8893627e983eac577b9920497f926f12c0e98271
All (non-test) invocations use the same second argument `Ok` (which
actually acts as a 1-arg closure `|v| Ok(v)`), so no need to have it as
a parameter. The common second argument just maps `Ok(v)` to `Ok(v)`,
which means that `map_err()` can be used instead of `map_or_else()`,
and the same type parameter is used for both input and output.
Test: legacykeystore_test
Test: keystore2_test
Flag: None, pure refactor
Change-Id: I46b6e327d0b546df6be6664781a52bb888c04eca
Test: Run `adb shell rkp_factory_extraction_tool
--output_format build+csr` on a device AVF RKP HAL is unsupported
Change-Id: I8f1ffa63710be6f566fb6f0800c45f3cfb907d69
Pass around information about which code is performing an exclusive
database transaction, and run an additional watchdog inside the
transaction closure.
Bug: 319563050
Test: CtsKeystoreTestCases
Change-Id: Ib54f1f4c0c37f9d7392d21d9ccb880d066029945
Almost all uses of the watchdog use the same 500ms timeout, so add a new
method that assumes that.
Test: CtsKeystoreTestCases
Change-Id: Idf7852400a58ba954e4a71e5e2282734a0960072
Calls to `with_transaction(Immediate, ...)` act as an exclusive lock on
the Keystore database, because the sleep-loop does not release the
transaction. That gives the potential for deadlock if any of the code
in the invoked callback takes some other lock without consideration
for lock inversions.
There isn't (yet) a smoking gun that definitively identifies a lock
inversion, but this CL adds timeout behaviour just in case.
Include a unit test that deadlocks without the code change, because
of an explicit lock inversion between the immediate-mode database and a
`KeyIdGuard` object (which acts like a `MutexGuard`).
Bug: 319563050
Bug: 315165314
Flag: android.security.keystore2.database_loop_timeout
Test: keystore2_test#database::tests::test_key_id_guard_immediate
Change-Id: I34fa044ce8e3185a89084b84c6f9ac880944982c
The original getService doesn't start the AVF HAL if it is
not already running. waitForService is used here with a timeout
of 10 seconds as it starts a service lazily.
Bug: 339118043
Test: m rkp_factory_extraction_tool
Change-Id: I942f4c5e1aae8b529895a51f19b525033609d0aa
Adjust the keystore2 client tests to cope with a wider variety of
underlying KeyMint / Keymaster devices.
A couple of these changes involve test modifications to match the
behaviour of the KeyMint VTS tests:
- `keystore2_gen_key_device_unique_attest_with_default_sec_level_unimplemented`:
Allow an extra error code, to match
`DeviceUniqueAttestationTest.EcdsaNonStrongBoxUnimplemented`.
- `keystore2_import_ec_key_success`: Skip the check that EC keys can be
imported without an explicitly specified `EC_CURVE` on pre-VSR-V
devices, to match the equivalent logic in the VTS tests
(`ImportKeyTest.EcdsaSuccessCurveNotSpecified`).
The other two changes are:
- `keystore2_gen_key_auth_boot_loader_only_op_fail`: Drop this test, as
it's the first/only place that exercises the optional
`BOOTLOADER_ONLY` tag. (The KeyMint VTS tests would be the best place
to exercise this for the first time.)
- `keystore2_ec_25519_generate_key_fail`: For now, skip the check that
an Ed25519 key should reject use of any digest value other than `NONE`
(on account of Ed25519 having its own internal digest). That behaviour
isn't quite right, but which is not currently tested by the KeyMint
VTS tests and so we can't require existing devices to be modified to
pass the check.
Bug: 336695416
Test: keystore2_client_tests
Change-Id: I06e90c859f33d8b4125541a67709ec67e8898c60
Looks like the DB was moved out of SQLite in aosp/1699645 but the
connection-holding type was missed.
Bug: 333894699
Test: TreeHugger
Change-Id: I4b87690343bc890cb1aa1c6e1595ac4b42c11670
On a rkp-only device it is not possible to generate an attestation
on a bare key generation (attestations can only be generated if an
ATTEST_KEY is provided).
Bug: 329409739
Test: keystore2_legacy_blobs_test
Change-Id: Icdc4037466ab32366c34feeb42b58822ea110ebf
... because there can be many many inputs for fsverity manifest
generator.
Bug: 330282551
Test: m aosp_cf_system_x86_64
Change-Id: Ic84205342a07002f2a72a2b412a14e7e01b46af3
error: field `0` is never read
--> system/security/keystore2/src/database.rs:848:31
|
848 | pub struct PerBootDbKeepAlive(Connection);
| ------------------ ^^^^^^^^^^
| |
| field in this struct
|
= note: `-D dead-code` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(dead_code)]`
help: consider changing the field to be of unit type to suppress this warning wh
ile preserving the field numbering, or remove the field
|
848 | pub struct PerBootDbKeepAlive(());
| ~~
error: aborting due to 1 previous error
Bug: 330185853
./test_compiler.py --prebuilt-path dist/rust-dev.tar.xz --target aosp_cf_x86_64_phone --image
Test: m rust
Change-Id: I4cb81c955372c4f8f50b940b389f2d7cfc5d3ce9
Remove IKeystoreMaintenance#onDeviceOffBody(), as it's no longer called.
In addition, remove the code that tried to enforce the AllowWhileOnBody
key parameter. This code was broken during the rewrite of Keystore in
Android 12, and as a result, AllowWhileOnBody has no user-visible
effect. AllowWhileOnBody is *supposed* to cause the key's
authentication timeout, if it has one, to automatically expire when the
device is removed from the user's body. (A better name for it might
have been something like UserAuthenticationExpiresWhenRemovedFromBody.)
Android 11 Keystore implemented this behavior; see
https://android.googlesource.com/platform/system/security/+/refs/heads/android11-release/keystore/auth_token_table.cpp#165
Android 12 Keystore changed AllowWhileOnBody to have no effect.
Apparently due to a misunderstanding, the (incorrect) behavior that was
attempted to be implemented was "The key may be used after
authentication timeout if device is still on-body". But what was
actually implemented was that the Keystore daemon stopped enforcing
authentication timeouts for AllowWhileOnBody keys entirely, except after
a wearable device was removed from the body in which case the timeout is
enforced for any earlier authentications. Yet, this has no user-visible
effect because KeyMint still enforces the authentication timeout as
usual. So, AllowWhileOnBody has really been a no-op since Android 12.
We can always bring this code back, fixed and with tests, if this
feature comes back. But for now there is no reason to keep it around.
Bug: 289849354
Test: atest -p --include-subdirs system/security/keystore2
Test: atest CtsKeystoreTestCases
Change-Id: I4a7b3a90b56dacbb5316e30a30bf3fabc0debe48
This uses the new macro for structured logging that simplifies the usage
of structured logging.
Bug: 290589708
Test: Run keystore client and checked the log
Change-Id: I4d941d8b03c09d0541cf1159c38f4eba60e07292
