GitLab

* commit 'a9a17eec':
  Mark 0 length files as corrupt

Files created by keystore should never be 0 length however a vendor ran
into such a case when testing their keymaster and a side effect of how
keystore parses files leads to these keys being considered encrypted and
ulitmately undeletable.

Now mark 0 length files as corrupt in readKey and when deleting a key if
the key fails to read in because it was corrupt simply rm the file since
it is not possible to feed the key blob to keymaster's delete method.

Bug: 22561219
Change-Id: Ie8c1ffe97d1d89c202cdab7a6b4b5efc914cbbff

* commit '06114e6a':
  Fix erroneous reporting of all tokens as timed out.

Bug: 22205545
Change-Id: I170e798b327020ff741031ec05e875c685a49e9d

* commit '5f042153':
  Rename keymaster tag types to clarify that integers are unsigned.

Bug: 22008538
Change-Id: Id6e3ca5c1defc8149b7ae7de5787b3635e2a4262

* commit '0ebf13db':
  Rename keymaster tag types to clarify that integers are unsigned.

Bug: 22008538
Change-Id: Id6e3ca5c1defc8149b7ae7de5787b3635e2a4262

* commit 'b913aa57':
  Abort operation pruning only if it fails to make space.

* commit '4e88f9be':
  Don't ignore errors from begin operation.

keystore service's begin operation may sometimes encounter a situation
where the underlying device's begin operation fails because of too
many operations in progress. In that case, keystore attempts to prune
the oldest pruneable operation by invoking the underlying device's
abort operation. Regardless of whether the abort operation fails,
keystore then removes the operation from the list of in-progress
prunable operations.

The issue is that when the underlying device's abort operation fails,
keystore fails the begin operation that caused all this prunining.
This is despite the fact that keystore has managed to make space for
one more operation.

The fix is to fail the begin operation only if the pruning attempt
did not make space for a a new operation.

Bug: 22040842
Change-Id: Id98b2c6690de3cfb2a7b1d3bdd10742cc59ecbfa

This fixes a bug introduced by
9221bff2 which invoked authorization
checks after begin operation, while ignoring any errors returned by
that operation. This CL restrores the correct order: authorization
checks are followed by begin operation.

Bug: 22039986
Change-Id: I3516cb120c21b9659289faa5d1ca0225df35a06d

* commit '53752414':
  Fully support uint64 key validity dates.

This fixes the issue where, on 32-bit platforms, keys expiring after
about 2^31 - 1 seconds since epoch (Jan 19 2038) might be treated as
already expired.

The issue was caused by using time_t (signed 32-bit on 32-bit
platforms) as current time and downcasting uint64 activation and
expiration time instants to time_t to compare them to current time.
This downcasting could make future time instants appear to be in the
past on 32-bit platforms.

Bug: 22015107
Change-Id: Iae12019c3c019beb92d791fda80b622fa5c4ac4e

* commit '9221bff2':
  Add keymaster authorization policy enforcement to keystore.

Bug: 19511945
Change-Id: I76c04e8d3253ba490cedac53bbc75943ec68df1d

* commit '84c14f09':
  Remove exist check from doLegacySignVerify

exist requires the keystore exist permission which callers of
sign/verify may not have. Instead log key not found if begin returns
::KEY_NOT_FOUND.

Bug: 21658885
Change-Id: I8c42f3a636a248e3fb1f0344bf32667fce57f667

* commit 'b2ffa420':
  Don't check authorizations for pubkey operations.

Bug: 21877150
Change-Id: I43dafb66fc3246f4d8e3bf4743fbdcbe072468d1

* commit 'fd92fe14':
  Track keymaster method changes

* commit '8521f7a4':
  Remove references to Google in Android keymaster.

Change-Id: If0b274118a2d238b18c0a06ee3fe7f0798a44a1c

* commit '3a7d9e62':
  Rewrite legacy methods in terms of new methods

Rewrite generate, import, get_pubkey, sign and verify using the new
keymaster 1.0 methods (generateKey, exportKey, and begin/update/finish).

This also removed DSA support from generate and import.

Change-Id: I6c6baec4aa86325a2b9c171b9883ba5a0b47236e

* commit '3cc40125':
  Allow keymaster 0.3 keys to interopt with keymaster 1.0 methods

Keymaster 0.3 keys are all valid keymaster 1.0 keys, so allow get to
return a keymaster 0.3 when looking for a 1.0 key to allow new methods
to work on old keys.

Change-Id: I20a32e39769a548224bcca7a42ef967285431c5d

* commit 'f82cd5c8':
  Add optional additional entropy to finish

If provided the extra entropy will be added to the device before calling
finish. If entropy is provided and the device does not support supplying
additional entropy then finish will fail with KM_ERROR_UNIMPLEMENTED.

(cherry-picked from commit 8cfb8ac6)

Change-Id: If26be118bf382604f6f8e96e833b76e6f9e94d58

Change-Id: I66294362fe272a424d5be65171ca6ddcb8287aaf

* commit '8c683b98':
  Use keymaster adapter to support older devices

* commit '9ac7a27a':
  Fix potential use-after-free in hw auth token handling.