GitLab

am 8a2c33b6: (-s ours) am 48d998cd: am aca71139: am 738d1e9d: am 1b8885ba: am 0d593526: Properly check for Blob max length

* commit '8a2c33b6':
  Properly check for Blob max length

* commit '48d998cd':
  Properly check for Blob max length

* commit 'aca71139':
  Properly check for Blob max length

* commit '738d1e9d':
  Properly check for Blob max length

* commit '1b8885ba':
  Properly check for Blob max length

* commit '0d593526':
  Properly check for Blob max length

sizeof(mBlob.value) is incorrect because writeBlob pads up to the next
AES_BLOCK_SIZE

Bug:22802399
Change-Id: I377edca2c7ea2cf4455f22f5f927fdad79893729

sizeof(mBlob.value) is incorrect because writeBlob pads up to the next
AES_BLOCK_SIZE

Bug:22802399
Change-Id: I377edca2c7ea2cf4455f22f5f927fdad79893729

am c761a1ed: (-s ours) am 63bc525c: am 853b8d79: am fd1ad379: am 1c73457a: am b124c9e8: Fix unchecked length in Blob creation

* commit 'c761a1ed':
  Fix unchecked length in Blob creation

am 63bc525c: am 853b8d79: am fd1ad379: am 1c73457a: am b124c9e8: Fix unchecked length in Blob creation

* commit '63bc525c':
  Fix unchecked length in Blob creation

* commit '853b8d79':
  Fix unchecked length in Blob creation

* commit 'fd1ad379':
  Fix unchecked length in Blob creation

* commit '1c73457a':
  Fix unchecked length in Blob creation

* commit 'b124c9e8':
  Fix unchecked length in Blob creation

Applications can specify arbitrary blobs using insert(), check their
length to prevent overflow issues.

Bug:22802399
Change-Id: I4097bd891c733914df70da5e2c58783081d913bf

Applications can specify arbitrary blobs using insert(), check their
length to prevent overflow issues.

Bug:22802399
Change-Id: I4097bd891c733914df70da5e2c58783081d913bf

Bug: 22556114
Change-Id: I44fda03305ddd50cb4ba3c6f6b24cfd9c2af9659

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

Bug: 22205545
Change-Id: I170e798b327020ff741031ec05e875c685a49e9d

Bug: 22008538
Change-Id: Id6e3ca5c1defc8149b7ae7de5787b3635e2a4262

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

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

Bug: 19511945
Change-Id: I76c04e8d3253ba490cedac53bbc75943ec68df1d

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

Bug: 21877150
Change-Id: I43dafb66fc3246f4d8e3bf4743fbdcbe072468d1

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

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

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

The operation map caches the hw_auth_token used to start the operation
but it was storing the pointer returned by the auth token table and not
the token itself leading to a potential use-after-free if the token was
removed from the table between the operation starting and completeting.

The operation table now stores the auth token itself instead of the
pointer provided by the auth table.

Change-Id: I80fd49655ed98e7879d2caa7f1ae077ff50e0e54

Change-Id: If0b274118a2d238b18c0a06ee3fe7f0798a44a1c

The keymaster adapter wraps the hardware module to allow keystore to
call the new keymaster methods on it and continue using old keys created
by that device with the new methods.

Change-Id: Ica08d81c3707023d378ad5fe6562dc642f58ca90

Change-Id: Ib7f4996d2e2002db4892d5585761a053f6698495
(cherry picked from commit e1faa9fe)

Also, remove unneeded inclusion of key_blob.h.

Change-Id: I05de61353fc806b90232fab7c1d1cf76aefa35fc